Re: Serialization : Discussion Summary

From: quendezus (quendez_at_[hidden])
Date: 2002-03-01 05:12:44

--- In boost_at_y..., "rameysb" <ramey_at_r...> wrote:
> Permit me to attempt to summarize the recent discussion:
> 
> ...
>
> b) implementation of archives in terms of istream/ostream. no 
> registered objections.
>

I am a bit uncomfortable with this iarchive/oarchive system. In the 
previous discussion about persistence on boost, we had a hard debate 
about what should be the archive class. An idea was that it could be 
a template parameter.

>
>    I would propose that two new classes be created - say 
> binary_iarchive
>    and binary_oarchive that would use binary rather than text 
output.
>    This would:
>    i) not be very hard to do.  Only a small part of the iarchive and
>       oarchive classes are particular to text/binary i/o.  These
>       sections could be moved to derived classes.
>    ii) It would mean that save/load functions would suffer no 
changes.
>    iii) programs could select binary/text archives at runtime by
>       choosing which variation of archive to use.
> 

I think a binary archive is necessary. But what next? What about a 
XDR archive? Maybe it would be possible to let the user decide what 
the type of the archive is. After all, the framework does not use the 
archive a lot: it mainly passes it from the caller to the save/load 
functions. For example:

-----------------------

// Framework (namespace boost)

template < class Archive, class T >
void serialize( Archive& a, const T& t ) { ... }

-----------------------

// User code

#include "binary_stream.h"

class Plane	{ ... };

void save( binary_stream& s, const Plane& p ) { ... }

int main( )
        {
        Plane p;
        binary_stream s( "save.dat" );
        boost::serialize( s, p );
        }

-----------------------

An advantage of this mechanism would be the separation between the 
serialization framework and the archive/stream part. Different 
streams or archives could be developed and plugged into the 
framework. And the debate about text vs. binary would be less 
important (I think this debate is endless because the choice depends 
of the usage).

Some problems to resolve in such a system:
1- Sometimes the framework needs to write some data (type 
description, etc.) into the stream/archive. 
2- Sometimes the framework may need to store temporary data into the 
stream/archive object (for deserialization of cyclic graphs for 
example).
So maybe the archive type should have some minimal requirement, or a 
type trait should be provided.

Sylvain