From: Robert Ramey (ramey_at_[hidden])
Date: 2003-04-16 12:18:24
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk