Re: [boost] Serialization Mailing list

From: Dave Harris (brangdon_at_[hidden])
Date: 2002-12-13 10:06:37

In-Reply-To: <20021211235210.36360.qmail_at_[hidden]>
On Wed, 11 Dec 2002 15:52:10 -0800 (PST) Augustus Saunders 
(infinite_8_monkey_at_[hidden]) wrote:
> In a nutshell, I gave these definitions:
> 
> Persistance == Transformationless && Symmetric
> Serialization == Lossy && (Symmetric || Asymmetric)

I think the terms on the right are more useful than the terms on the left 
:-) Here is a more detailed set of discriminating questions that we can 
ask:

o  Is the format symmetric? Can saved objects be reloaded without loss?

o  How easily can the format be understood by humans? Eg does it need
   decoding like a hex dump, or is it readable by techies like XML, or
   is it suitable for use by non-technical end-users like the output of
   a report-generator?

o  How portable is the format between applications/compilers/platforms?

o  How verbose is the format? How efficient in time and space?

o  What cooperation does the format need from the user-defined type?
   Is any UDT-specific code needed at all? Can types be loaded without
   changing their source code?

o  What variations in schema can be accommodated? How much does this
   depend on hand-coding in the user-defined type, and how much is
   managed automatically from met-data in the archive?

o  How much redundancy is there between loading and saving? Can a
   single routine or set of metadata do both jobs?

o  What validation does the archive provide? Can the archive detect
   gross corruption? Are integers checked against user-defined ranges?

Robert Ramey's submission had a particular set of answers to many of these 
questions. For example, he seemed to believe that only symmetric formats 
should be supported and that it did not need to be human readable. My 
feeling is that the scope can be broadened fairly painlessly, at least a 
little further.

> Further, you have identified a couple of types of transformations
> that you feel are important.  Well, as I think the original
> discussion showed, people have a wide variety of desired output
> types and styles

It would be helpful to collate a list of candidate format types and 
styles. 

My fear is that some format types will turn out to be incompatible with 
each other. That if we support, say, XML, we will prevent support for some 
other format. (I think this danger is why Robert didn't want to go down 
this path.)

My hope and tentative belief is that, on the contrary, any system which 
can support XML will be compatible with all other formats. I welcome 
counter-examples.

-- Dave Harris