Re: [Boost-users] [serialisation]Portable Binary Archives

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