Re: [boost] [Serialization] Formal Review

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-19 12:26:56

Matthew Vogt wrote:

* What is your evaluation of the documentation?
...
> I think the documentation addresses extending the library with
> serialization of external types better than it addresses extending the
> library with new archives (although, this is probably a biased view :) )

True. I didn't anticipate this much interest in making new archive classes.
Also making a new archive class is harder than specifying a new
serialization so I spent less effort on explaining it.

> That said, the library seems not to limit anything an archive implementor
> may want to do. My only remaining concern is regarding controlling access 
> to indiviual overloads of 'save' or 'load'.  This seems to break down, due

> to the fact that all accesses are from the 'access' class.

I would be curious to see a specific example of this.

4) Finally, I would like reviewers to indicate parts of the library that
might become standalone boost libraries.  While this will have little
bearing on the acceptance / rejection of the library it might allow a
reduction in the size of the library.

Some sections of code are definitely candidates for extraction from the
serialization library, largely identified by Robert in the 'Miscellaneous' 
section of the documentation.

The strong typedef and state_saver utilities could be extracted, perhaps to
the utility library.
Perhaps the extended type info infrastructure is useful outside the library.

> The dataflow iterators are very interesting, but I'm not sure how they
> interact with the iterator adaptors library, or with sandbox views
> library.

I would love to see separate discussion of this (on a separate thread
please).  This area overlaps with iteratator adaptors and views an maybe
collection traits and who know what else. This is something I've always
wanted and now I (almost) have it.  My current implementation (not yet
uploaded) is much improved but has the same interface and intention. 

> The unicode conversion code is certainly useful, but I imagine it might be
> better to leave it as an implementation detail of serialization, until
> someone volunteers to investigate a complete solution for this issue. 

I would love to see someone take this out.  Ron Garcia wrote this and it
worked to my satisfaction.  I had problems making a good test and with
portability to other compilers/libraries.  Maybe Ron or someone else wants
to move this to somewhere else. 

Robert Ramey