Re: [boost] Serialization Draft Submission # 2

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-03-25 02:12:09

 >Date: Thu, 21 Mar 2002 16:37:43 -0500
 >To: boost_at_[hidden], boost_at_[hidden]
 >From: Beman Dawes <bdawes_at_[hidden]>
 >Subject: Re: [boost] Serialization Draft Submission # 2
 >Reply-To: boost_at_[hidden]

 >At 03:30 AM 3/21/2002, Vladimir Prus wrote:

  >>I thought, however, that there should be some another level, which 
manages
  >>translation between the objects into calls to low-level functions that
  >>store ints and chars. Now I see a problem: in order to make sense of XML,
  >>it should use reasonable names, and look like
  >><green_crocodile>
  >>	<age>7</age>
  >>	<weight>200</weight>
  >></green_crocodile>
  >>However, there's no was to get names "green_crocodile", "age" and 
"weight"
 > >without user's help. So it's not possible to get reasonable XML
  >>automatically.

 >While it might not be possible to do that "automatically", Jens' design 
 >made it trivial to supply a writer or reader that would handle 
 >"green_crocodile", "age" and "weight" XML. That should continue to be 
 >trivial, IMO, or a design really comes into question.

 >Users really do want a serialization library, but they have high 
 >expectations.

 >--Beman

I originally reviewed jens documentatoin and code and really failed to understand how it was designed to be used and how it  worked.  I did study it but the operation and usage was not obvious to me.  It was apparent that it did not include things that I considered indispensible.  Mainly, serialization of pointers and versioning.  It was also unclear as to how base class data was to be handled

To properly respond to this question, I have gone back and reviewed jens design once more more carefully.  

I still don't feel I understand it very well but I believe It turns out (as it must) there are certain things in common:

jens design includes overridable readers and writer
my design includes overridable input and output archives

jens design includes save and load functions for user types and non user types
jens design includes a "describe" function which overloads the & operator so that
one can write:
        descriptor & a & b ...
instead of
        save(ar)
                ar << a
                ar << b
        and
        load(ar)
                ar >> a
                ar >> b

in my design, override of save/load of primitve types is done in the archive
there is no describe facility

The above is the basis of my views on the questions raised above

 >While it might not be possible to do that "automatically", Jens' design 
 >made it trivial to supply a writer or reader that would handle 
 >"green_crocodile", "age" and "weight" XML. That should continue to be 
 >trivial, IMO, or a design really comes into question.

Given the correspondence between input and output archives and readers and writers, it should be equally easy or difficult to implement an XML file in either one.

I have looked at this in a cursory way and concluded that its anything but close to trivial in either design.

The main issue would be what would be the purpose of such a package.  It would be to share data with other applicaitions, one would have to build an XML parser that could handle all legal XML.  If it is just to recover the state of C++ objects, then what wold be the point.

 >Users really do want a serialization library, but they have high 
 >expectations.

Well I have high expectations myself.  Draft submission number 2 added all the features requested by boost members except describe.

XML
===
Personally, I do not believe support for XML can be accomplished simply by overloading existing functions.  I believe that XML would alter things in a more fundemental way. If someone want's to prove me wrong by providing the appropriate overrides, great we're done.  Otherwise I would like to defer XML compatibility as a subsequent enhancement.  Coincidentally, this months MSDN starts a three issue series explaining built-in serialization of the Common Runtime Library.  This a whole separate facilty apart from their XML parsers.   I belive this is a reflection of the fact that XML and serialization do not have as much in common as it would seem at first.

describe
======
basically I saw describe as a thin layer to invoke save/load functions.  In my personal view it obscured the operation and usage of the package rather than making it easier to use.

More importantly, describe presumes symetry between load and save which doesn't exist.  The most obvious case is versioning, but there are others such as saving and loading enums.

Finally I would encourage all those who requested features with the serialization package to try draft version number two currently on the server.  I believe this has been done by only one user.  He found the package to function after a couple of minor changes for his platform.   His feed back was invaluable.

It is my intention to concentrate on addressing any bugs found and portability problems.  I am extremely reluctant to consider adding new features.  Any new features can be added to a subsecuent version.

Robert Ramey