Re: [boost] an xml-binary persistence library

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-04-16 02:22:12

Nicola Santi wrote:
> Hi,
>
> I would like to submit to your attention eternity, a free library I’ve
> first released at the end of last millennium.  I think it could match
> some technical requirements to become part of boost library (xml and
> binary persistence, stl containers support, ANSI compliant, name
> conventions, and so) and I know it has been useful to over 2.000 people
> in the world since now.

Hi Nicola,

A serialization library is a thing that a lot of people want. Some time ago,
Robert Ramey suggested a library of his own for Boost. It was not accepted 
at that time, but I believe there was general desire to see it improved and 
resubmitted.

Certainly, you are free to sumbit your library separately, I just wanted to 
point out there was prior efforts here, in case you'd like to cooperate.
The URL for the latest version is: 
http://groups.yahoo.com/group/boost/files/serialization6.zip

Now, to your library. I have a bunch of comments, hopefully constructive.
In short, a *much* better documentation would be needed to make practical use 
of the library. I also see two design problem and one implementation problem 
(marked as DP and IP) below.

1. The documentation on the web page could be better.
   - I don't see "overview" anywhere. I see such
     document in the distribution, but if you don't have overview instantly
     accessible, some folks will not even bother to download the library.
   - The "examples" web page does not contain examples, but just mentions the
     ones from distribution. Having examples on the web would be much better.

2. (DP) Binary serialization and XML serialization are entirely separate. You 
need to declare two different "searialize" functions, and binary_archive and 
xml_archive have little in common --- the base class "archive" has minimal 
interface without any virtual functions, so you actually cannot use "achive" 
itself. I see this as a big drawback. It must be possible to use one function 
for both binary and xml, to reduce code duplication.

3. (DP) Your "serialization" function is non-const. Does you mean I cannot 
serialize const object (except by using const_cast)?

4. I don't understand how serialization of base classes should be done. In 
your example "examples/binary", base classes don't have "serialize" member, 
and the derived one stores the base members directly.

5. I don't understand the difference between operator operator<< 
and put_object. The first just writes sizeof(T) bytes from the address it is 
given. Therefore, you can use it only for storing builtins and PODs -- not 
for pointers or classes with virtual functions. It would be nice to enforce
this restriction. 

(IP)
Then, if you use put_object for storing pointer to nonpolymorphic class, 
you'll still store typeid(..).name() for the pointer.
Moreover, if you store a several different pointers to the same class, you'll 
have type name stored many times, and it's likely it will be longer that the 
class data!

6. I believe there's not enough tests for your library. 

7. (thinking aloud) Recently, I was thinking how to improve loading/saving of
some file format at work. The file just consists of 'events' of different 
kinds and you can say that each 'event' is a class derived from common base.
In fact, I need to store just a number of polymorphic pointers. Okay, but:

- The space is important. A single class may be 4-ints big, and writing class 
name will double the size of data.
- The speed is important. In one case, the type of data is known during 
writing, and just raw bytes are added to a buffer. Adding "typeid" call and
a search for conventional name (you do it with linear search now, but map is
not O(1) as well), will not be acceptable.

I recalled that someone suggested to Robert to separate class registration to
a separate component (possibly replacable). That would be very good here. I 
could create custom class which will return id for a type at compile-time. 
What do you think?

8. The reference docs are not complete. Many comments leave a lot of 
questions. For example:

    int eternity::archive::put_pointer (  void *  object ) 
   Verify that object is stored only once. 

It does not say what's "verify" and what value is returned. Or:

    template<class t> 
    t* eternity::bin_archive::put_object ( t *   pObj ) [inline]
    Put an object pointer in the archive. 

This tells nothing about what can be 't' (it can't be builtin type, right?)
and what really happens.

And, BTW, why 'put_object' is inline? It's quite a big function and if 
compiler respects your hint to inline the function, you might get unexpected
code bloat.

9. Your Makefile for binary/GNUMake is wrong: you don't set
dependecy from object files to sources. 

> That’s the reason of this post, I would like to discover:
>
> - Firstly, if there could be some interest from boost community to add
> my persistence engine to your libraries and

That's a question. I voted against Robert's library because:
(1) the registraction of polymorphic classes was brittle from my opinion
(2) there was not way to extend it to XML

The problem with your library is that I'm not sure (1) is addressed in a 
better way and your implementation has more overhead. The problem with (2) is 
that it's entirely separate from ordinary serialization.

- Volodya