From: Cliff Green (cliffg_at_[hidden])
Date: 2007-06-27 12:56:33
> This is something that is really needed in boost. Could
>you
> possibly:
>
> a) make a small boost library for this which would
>include
> i) code (hopefully header only?)
> ii) tests
> iii) documentation
>
> and ask for a mini-review.
>
> b) enhance the portable binary archive to take advantage
> of your code.
>
> c) enhance the serialization documentation to explain
> that portable binary archive.
>
I realize I need to look at the current portable binary
archive example code to better understand the design
tradeoffs, but there's a number of possible approaches to
consider. To me, it makes sense to have multiple portable
binary archives, allowing the app to make the best choice
for its need (maybe a good "compromise" binary archive
could be the default for Boost.Serialization).
Possible choices (some already discussed):
1. Absolute smallest space - e.g. "continuation" bits,
allowing integers to be 1, 2, 3, 4, etc bytes in size,
depending on if the value is (respectively) 127 or less,
32767 or less, etc. (I'm pretty sure this has been
discussed before). There could even be a "bitstream"
packing versus byte-oriented, but the set of users for
that might be pretty small (I've written "bitstream"
protocols for wireless networks before, and believe me,
the compactness is significantly more than the usual
binary network protocols).
2. Absolute fastest speed - XDR fits this, as it is not
all that space efficient (e.g. bools take up 4 bytes,
short ints take up 4 bytes, etc). But it definitely is 4
byte aligned in everything (however, I would guess that
the speed differences regarding alignment are much less
for modern processors versus when XDR was first defined).
3. Flexibility versus simplicity - e.g. whether object
ids, tags, implicit structuring and nesting, etc are
directly supported versus just providing support for
fundamental types, and (relatively) simple sequences.
4. Floating point support - IEE 754 formats only versus
later standards (and long double), other non-typical
floating point formats, and probably a host of other
possibilities for binary floating point.
5. Adherence to a commonly used (or even not that commonly
used) protocol - XDR, CDR, etc.
Cliff