RE: [boost] Serialization Review Results

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2002-12-09 18:21:44

> 2. Careful description of scope. Answer questions like: 
>      * Is this a persistence or serialization library?
serialization
>      * Is it important to be able to plug in arbitrary archive
>        formats?
Yes
>      * Is it important to be able to use the same UDT serialization
>        code to write several different archive formats?
Yes
>      * What kinds of applications are we intending to serve?
1. Serialization for transferring data to differrent process/compiter. This
couls be subdivided application that targeting minimal size/speed or open
format (like XML)
2. Serialization for the purpose of storing current state of the application
(like storing the document in windows applications) for future reading by
the same application (or another that has an access to the same headers).
Sounds more like task for persistence library as it was defined above.
Though IMHO I do not see a problem with supporting such functionality in a
bounds of this library.

2. Serialization for 
>      * What kinds of applications are we explicitly NOT intending to
>        serve? 

Storing data into database(-like) storage?

> 
> 3. Careful consideration of the appropriate interface for describing
>    the serialization of UDTs on a conforming compiler. In particular,
>    consider the lexical cost of requiring users to specialize library
>    templates. Also consider that the use of operator<< is going to
>    invoke ADL anyway, so maybe the interface should just use

ADL?

>    that. Serialization of class template specializations and other
>    classes should use the same mechanisms.

On conformant compiler.
 
>    * Dave Harris suggested several times that integers should be
>      written in the binary archive in a variable-length format.  This
>      echoes a philosophy on serialization which I've had for years,
>      provides many benefits and would seem to allow drastic
>      simplification of the library if it is decided that the current
>      scope will be retained, since it entirely obviates the need a
>      text archive format (the same could be done for floating point
>      numbers). The only application I can imagine this approach being
>      unsuitable for would be extremely fast, relatively small
>      in-memory archives... and I'd have to see benchmarks and a real
>      use-case to be convinced of that.

I do not think we should enforce specific portable binary presentation. 
1. There is no such task to present portable binary presentation
2. "you don't pay for what you don't use". I may not bother. Even if it
costs almost nothing.
 
>    * Boost already has a mechanism for registering inheritance
>      relationships and convertibility among classes. It's not part of
>      the public interface, but is an implementation detail of
>      Boost.Python. Should this be exploited for serialization?

Does it rely on type_info?
 
>    * Objects without default constructors really should be
>      deserializable.  One possible approach is offered by Python's

They are now.

>    * Is it important to allow all UDTs to be separately versioned?
>      Every time I have implemented serialization and started with such
>      a system, I eventually dropped it in favor of a whole-archive
>      version number.  Changing the format of a single class always
>      creates a backward compatibility problem for new archives anyway.
>      Allowing the archive to carry the version number also simplifies
>      the [de]serialization interface.  If separate versioning is in
>      fact important and useful, a rationale should be provided.

As I mentioned in my review it should be user managable. Some want, some
don't want to have per-type versioning

>    * Strong consideration should be given to a "you don't pay for what
>      you don't use" approach.  As Ralf Grosse-Kunstleve pointed out to
>      me, C++ is not really good at serialization, natively.  One of
>      the only reasons to use it instead of a language with stronger
>      reflection capabilities has got to be that it is fast.  Avoiding
>      virtual function calls for serializing large arrays of small
>      objects (e.g. complex or rational numbers) must be possible.

I pesented in my review one way to implement "optional" virtuality (the same
as in "C++ templates" book, just published).
 
Gennadiy.