Re:Re: [boost] Serialization: versioning and XML.

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-01 12:04:00

Anatoli Tubman wrote:

>It absolutely certainly will be a new archive class. Sorry if it wasn't
>clear from the start.

>I just think such an archive/serialization library is (a) useful enough
>to bea part of boost and (b) similar enough to the existing boost
>library to share the namespace with it.

I've got no problem with this.

>I understand fully that this idea works only with tagged formats (not
>necessary just XML), that's why I'm saying that it should probably
>use a different syntax or maybe a sub-namespace under boost::serialization.

Within the boost::archive namespace I've got things like:

basic_xml_iarchive
xml_iarchive
xml_wiarchive
etc.

I would think there is plenty of room for something like:

basic_tagged_iarchive
basic_tagged_xml_iarchive
tagged_xml_iarchive
tagged_xml_wiarchive
etc.

>I'm staying within program-structure-drives-data-format school of
>thought. 

As long as you can stick with this, I think you can be successful.  

I briefly considered this approach. I imagined that upon archive creation
the XML input could be parsed into a node tree. (insert plug for spirit
here) The load_override function would be altered to search the correct part
of the tree.  So this would work and be pretty clean.  I'm sure other
approaches such as using SAX or DOM to parse the tree would work as well.
Maybe there's another way I never thought of.

The main reason I rejected the idea was that I didn't see it working with
arbitrarily size streams. I envision serialization being used with stream
much larger then available memory.   This suggested to me an "on the fly"
loader rather than a "pre-loaded".  

My implementation does require that tags remain in sequence and are all
anticipated.  Your proposal wouldn't have this restriction and might be
preferred in certain applications.  

So I'm happy to encourage your efforts.  I also hope that other users will
be inspired to address more particular needs by creating their own archives
class variations.  In the long run, I'm trying to get out of the archive
creation business in the same way I'm trying to get out of the class
serialization business.

>I don't precisely understand how going in the other direction
>is ever useful. Okay, given a DTD, you can generate a program that could
>read and write a bunch of data structures; but what will it *do* with
>them?

I can see the need for and utility of this.  It's just that it's a whole
different problem than what serialization addresses.

Good Luck with this.

Robert Ramey