[boost] Re: an xml-binary persistence library

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-04-17 15:05:37

Vladimir Prus wrote:

>> iii) requirement to pre-register classes to be saved as pointers
>> through a base class

>Was it ever considered a problem. You surely have to register a class in
>order to deserialize it (Java can create a class given its name, but we're
>in C++).

I refering to the issue of "forward declaration" vs "module level registration"
We spent a quite of bit of time on this as well as type_info, etc.  I have added
 the "module level registration which I think would satisfy the concerns
you raised and conflict with my concerns.  But I want to pass through
it one more time to unitify the treatment of external type ids.  This
is in part inspired by G Rozenthal's concern that RTTI should not
be required.  I don't really share the concern.  But if things are factored
in the right way the external type id issue becomes a replaceable
component and we won't have to spend a lot of time on the issue.

>> iv) requirement to have separt save/load code for serialization functions

>I though about it just recently, and stubmled upon the issue of
>const-correctness. Probably, separate save/load is OK, since I don't know
>any good alternative solution.

I was always a fan of "const-correctness" that came with the save/load
system.  Also the save/load system permitted a finer granularity
such that a program that only read would only have to import
half the headers and library code.  (Same for programs that only
write archives).  However, I was sensitive to the redundance
of the save/load system and came to appreciate the 
usage of the & operator for both saving an loading - even at
the cost of const - correctness. (thanks to jens maurers effort) 
After trying out a number of alternatives I came to a solution which permits either
to be used on a class by class basis. 

>Can we have a look at it? Probably, putting it to boost-sandbox is good
>idea. I'm really interested to see how it applies to use case I have at
>hand.

I don't feel its quite ready for that.  Some things are still in the experimental
stage and I'm still weighng alternatives.  After these things are settled
I would better be able to provide explanations for the choices I made.
Please send me your use case.   I am very interested in it.

Hopefully soon I will have the package working at the level I desire.  Then
there's a huge amount of work (re)writing and expanding the documentation
and finer granularity test cases.  oh then there's the jam build. and then
making things work on more compilers,etc.  In all its a very large job.

So my preferred plan would be:

a) finish what I'm doing as far as features are concerned
b) expand documentation a minium amount
c) expand test cases a minimum amont
d) send it privately to boosters who have shown a special
interest in this package
e) make some more changes
f) If there's still interest, upload it to CVS
g) see what happens.

This would still be a couple of months away.

> b) versioning at the class level
>
>It would be nice, BTW, to have optional versioning....

The question about "optionality" features is much more intricate
than it first appears.  Other features that are candidates
for optionality are:

a) serialization of pointers
b) versioning
c) tracking of object addresses to eliminate extraneous copies
d) bypassing the serialization system for special cases

and some of these features interact with each other.  After 
much experimentation I have made a system which permits
selection of optional serialization features on a per class basis.

It turns out that ALL the issues raised in the review, including
those that I dismissed, are being addressed. I didn't really intend
 to do this  I had resolved to improve the quality of the implementation
 and leave most of the feature decisions unchanged as I saw them 
as ireconcilable trade offs.  I was much surprised to discover that
improving the implementation made apparent that what I had
thought were trade offs where in fact artifacts of implementation 
stratagy decisions.  

Note to potential library submitters: The boost review process is
far more rigorous than what one is normally accustomed to and I
suspect that few are really prepared for it.  On the other hand,
I have no doubt that this the reason for the incredible high quality
and utility  of the boost libraries.  The only thing I can't explain
why anyone would subject himself to this. Yet here I am.

oh well.

Robert Ramey