[boost] Review: serialization

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-11-18 15:42:59

I have several serious issues with the library, based on five hours of 
study of the documentation, headers, and sample code:

* tutorial.html - The examples led me think that it isn't easily possible 
to serialize a given class in more than one way (with more that one 
save/load descriptor).  An example of how to do this would be appreciated, 
such as serializing only on degrees and minutes (ignoring seconds).

* The lack of alternate archive formats is a showstopper, IMO.  I would 
expect to see text, CSV, XDR, platform specific binary, HTML, and XML 
either supported or at least discussed or given as example code. That is 
the only way to make sure that the hooks are present. If that seems like a 
long list, remember that doing proof-of-concept for those formats with 
Jens' library was not at all difficult. (Note that I don't personally have 
a need for all formats to support all C++ data structures. If a CSV (comma 
delimited) format doesn't support full pointer functionality, for example, 
that's fine with me.)

* I'm concerned that the library is so aimed at solving difficult problems 
(pointer issues, for example) that the simple use cases aren't being given 
enough consideration. Can't tell if this is just my misunderstanding, the 
docs need work, or there is a serious underlying problem. Perhaps layering 
like Boost.Test, or separation of orthogonal parts as described by Yitzhak 
and Vladimir is needed. I'll volunteer to contribute some use cases that 
concern me.

Less serious issues:

* Please use regular Boost directory structure sub-directories: 
doc/build/test/example

* overview.html/Requirements (7) "File portability - files created on one 
platform should be readable on any other." It is a requirement that 
portability be possible, but all formats are not required to be portable. 
Binary formats in particular should be free to choose platform dependent 
rules.

I'd also add:

10. Orthogonal specification of external (I/O) formats, including the 
ability to reorder or filter class members, and the ability to have 
multiple serialization formats for an object.

11. Reasonably easy to cope with common formats like comma separated value 
(CSV) that are created or consumed by a text editor or a DBMS or a non-file 
resource.

Presumably (11) is a side effect of meeting (10), but expressing it 
explicityly may help to alert people to the idea that the end consumer or 
provider for serialization data may be something other than the 
serialization library itself.

* rationale.html "Saved objects must be const." I understand the need that 
objects not change during a save or load, but surely you can't mean the 
objects are actually const themselves? The reference confused me even more 
regarding constness, where you say not to create constness via a cast. 
Maybe an example would clarify what you mean here.

* rationale.html - I was expecting to see rationale for why Jens' 
"describe" technique wasn't used.  It seems so much more elegant and far 
less error prone than writing separate save and load lists, so there should 
be a strong rationale for not using it.

* tutorial.html - First sample program -

void main() {
     // create and open a character archive for output
     ofstream ofs("filename", ios::binary);
     boost::oarchive oa(ofs);

     // create class instance
     const gps_position g(35, 59, 24.567f);
     // write class instance to archive
     oa << g;
     // close archive
     ifs.close();
     ^^^

Shouldn't that be ofs.close()?

It would be helpful to show the output of the that first example.

----
Based on the above serious issues, I vote no as the library now stands.
A lot of thought and work has gone into the serialization library.  I hope 
that Robert will continue his work on it, and clear enough issues that it 
can become part of Boost.
I also hope that those of us who have complained about aspects of the 
library will be willing to work with Robert to resolve the issues.
--Beman