[boost] Re: an xml-binary persistence library

From: Nicola Santi (nicola.santi_at_[hidden])
Date: 2003-04-18 16:05:08

 > b) Certain usage features
 > 	ii) inconvenient type registration requirement
 > 	iii) requirement to pre-register classes to be saved as pointers
 > 	through a base class
 > 	iv) requirement to have separt save/load code for serialization 
functions
 > b) your package has the same set of usage features (b above) that
 > mine did and these were strenuously objected to.

eternity, my library, use the same method for save/load  and do not 
impose to using any base class. Could you help me understand this point, 
expecially for b ii and iii ?

Thank you very much for your suggestions and honest words: if I could be 
of some help with your library, please let me know.

N.

Robert Ramey wrote:
> Nicola, Vladimir et.al
> 
> I submitted a serialization library for review last november.
> 
> It was rejected for inclusion in boost for a number of reasons which
> I will attempt to summarize as follows:
> 
> a) Certain capabilities were deemed necessary were not included:
> 	i) inability to extend to XML format
> 	ii) inability to overload serialization to eliminate virtual function calls
> 
> b) Certain usage features
> 	ii) inconvenient type registration requirement
> 	iii) requirement to pre-register classes to be saved as pointers
> 	through a base class
> 	iv) requirement to have separt save/load code for serialization functions
> 
> c) Implentation quality was deemed below boost standards.
> 
> Other issues (e.g. better documentation - compatibility with more platforms)
> were not disputed and in any case would be easily addressable.
> 
> Naturally I was pretty disappointed.  On the otherhand I have gone back to 
> work on the package.  I started with c) - implementation issues.  The basic
> problem was that the implementation had not been factored at a
> sufficiently fine - grained level and certain concepts had been mixed
> together.  Some particularly insightful reviews made me see this.
> 
> After addressing this, the path to addressing the main feature objections a and b
> became clear.  I believe that if I submit another version of my serialization
> library, it well meet all the objections listed above. I am currently implementing
> an XML archive.  
> 
> I did look at Eternity about a year ago.  It seems that the package has evolved
> since I looked at it and that features have been added that I thought would be
> necessary.   I downloaded your most recent version and given it only a cursory
> examination.   But I can make a couple of preliminary observations based on my
> personal experience.
> 
> In order to be acceptable to boost I believe it would require:
> 
> a) better documentation.  What you have (the PDF) isn't bad. Its just that more will
> be requested.  Personally I'm not impressed with the "Oxygen" automatic
> documentor (or any other automatic documentor).  
> 
> b) your package has the same set of usage features (b above) that
> mine did and these were strenuously objected to.
> 
> Should you submit this package other issues will be raised in excructiating detail
> such as:
> 
> a) independence of serialization code from archive format so that a different
> archive can be selected without changing the serialization code.  This would be
> a very important issue for many people
> 
> b) versioning at the class level
> 
> c) serialization of polymorphic pointers
> 
> d) tracking allocation of objects and subsequently serialized pointers to those objects
> 
> e) personally I find your XML implementation acceptable.  But I fear that others will
> want a more elaborate one which has DTD and or schema support. I don't know
> its just a feeling.
> 
> f) customization of policies for tracking of pointers, versioning etc.  A fundamental
> difficulty in making a library such as this acceptable for boost is the the idea that
> "You shouldn't have to pay for what you don't need" and "It needs feature ..." .
> Resolving the tendency for these goals to conflict is heart of making a library
> acceptable to boost.
> 
> I should say your package represents a clean implementation whose code
> is readily understandable to anyone how wants to understand it.  I believe that
> no major objections would be raised on these grounds.
> 
> Good Luck
> 
> Robert Ramey
> 
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>