[boost] Re: an xml-binary persistence library

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-04-17 09:49:29

Hi Nicola,

Nicola Santi wrote:

>  >4. I don't understand how serialization of base classes should be done.
> 
> In derive class serialization method remember to call the serialization
> method of base class.
> 
> void Derived::serialize( bin_archive &stream)  {
> // first base class serialization
> Abase::serialize(stream);

Ok, I see now.

>  > 5. .. Then, if you use put_object for storing ? 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!
> 
> put_object() stores the class conventional name than call the method
> serialze(). get_object() retrieves the conventional name, create the
> object, call the method serialize.
> 
> If you do not need dynamic creation (because you know it?s type or
> because it is allocated on the stack, etc.) create the object and call
> its serialize() method instead of get_object().

I'm afraid I don't like this approach. You have 3 ways to serialize an
object:
1. Call operator <<
2. Call put_oject
3. Call serialize on object directly. 

That's quite confusing.

> 7. (thinking aloud) ..
> 
>  >- 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.
> 
> Same as previous point, if you know the type don?t store it.  Otherwise
> if you need dynamic creation assistance the name of the class should
> necessarily has been stored in the archive: in this situation could be
> of some help register the class with short name only for the duration of
> storing and retrieving.

OK, short name will help with the space issue. But still, lookup up that
short name will take time.

>  > 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?
> 
> I think could be interesting, please let me know more details about the
> API you are suggesting and we could try to implement it.

If I only new what API I am suggesting ;-) The originally idea came from
something else, and it started to resonate with my needs recently. I'll try
to think about something concrete.

>  > 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.
> 
> I agree: I?ve change eternity web site this morning to follow your
> suggestions.

That's good.

 > 6. I believe there's not enough tests for your library.
> Again, your are right. Could you help me in writing more tests? I will
> appreciate it?

I think that Robert's library has quite a plenty of tests. You can look for
ideas there.

> DESIGN CONSIDERATION
> 
> 2. (DP) Binary serialization and XML serialization are entirely separate.
> 
> Storing a primitive type in xml archive required an additional field
> (the tag label) then storing the same field in binary archive. Moreover
> retrieve that field required one other parameter (the position) that is
> not needed in binary persistence.

BTW, I don't understand why tag is required on loading. I would suppose that
XML is just like binary stream, only you have extra annotations for the
benefit of humans and tools.

> One year ago a developer from French write me if it could be possible to
> have only one serialize() method to store both xml and binary way. I
> wrote the modification to eternity (moving a lot of methods from
> xml_archive to archive ) and having serialization method like this:
[..]
> When this method is called for binary persistence it passes a lot of
> parameters that are not using and loose the random access facility over
> XML archive. Do you really things it is a good idea? With two methods
> (serialize and xml_serialize) the class has more control over the
> persistence engine and could choice to implement only one of the two ways.

First, I don't yet get the idea of "random access facility". Thinking about
uneeded data, I though that if you had template method:

   template<class Saver>
   void save(Saver& s) const
   {
          s << class_name("foo") << field_name("x") << x;
   }

then a saver for binary data would have empty inline overloads for
class_name and field_name manipulators. The compiler will surely
optimize away all names manipulation and you won't pay for it.
A saver for XML would make use of names, of course.

> Ok, excuse me for this long reply (and my english). I have really
> appreciate your notes and I will be very happy if could help me again,
> as you wish. Let me know?

You know, Nicola, I will be willing to help anybody who can present 
really good serialization library. But since there's Robert's code
already, I don't know whom to help ;-) Both libraries appear to be similar,
so it would be nice if you cooperate somehow.

- Volodya