Re: [boost] Serialization Mailing list

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2002-12-11 18:52:10

I'm just reposting from the list:

*****************************original message***********************

Dave Harris wrote:

>>1. Agreement on terms. In particular, I strongly suggest beginning
>>   with the definitions of serialization and persistence outlined
by
>>   Augustus Saunders in
>>   http://lists.boost.org/MailArchives/boost/msg39598.php.  I
realize
>>   that Robert didn't like those definitions, but they resonated
for
>>   most people (including me), and seem to provide an excellent
>>   starting point.
>>    
>>
>
>For what it's worth, I didn't like those definitions. In my view 
>serialisation is the right name for what the submitted library did. 
>Persistence is just serialisation to a persistent medium.
Persistence is a 
>property of media rather than formats. It all but comes for free
once you 
>have decent serialisation.
>
This is, in fact, why we need agreement on terms.  At a fundamental 
level, we may not even agree on the significant axes of 
differentiation.  This is really the problem, not the labels that we 
apply to our distinctions.  We can call different catagories of goals

A, B, C, and so forth for all that it matters.

Since my definitions got pushed to the forefront, I'll try and
clarify 
why I made the distinctions I made and why I think it is a worthwhile

distinction.  In a nutshell, I gave these definitions:

Persistance == Transformationless && Symmetric
Serialization == Lossy && (Symmetric || Asymmetric)

The reason why I drew up these distinctions is based on how the user 
winds up using a library, and what information must be intrinsically 
provided (ie, can in no concievable way be automatically
deduced) to the library.  Basically, it is my feeling that if we
cannot
make transformationless persistance fairly transparent through type 
metaprogramming, then we need to go back to the drawing board and 
figure out what we need to make it fairly transparent.  On the other 
hand, anything that requires a transformation to be applied on the
data
being stored intrinsically cannot be transparent--somebody has to
write
the transformation.

So, from the perspective of library writing, Persistance should be a 
poster child for type metaprogramming.  Serialization, on the other 
hand, is a transformation framework, where we identify common modes
of 
transformation in order to make it easier for other people to create
their favorite transformations of whatever kind.  Application writers

would directly use a persistance library, but a Serialization library

would actually be for other library writers, with the exception of 
whatever sample transformations we cared to provide as examples.

In defence of my terms, the purpose of Serialization is to encode
data
as a serial sequence of bytes.  The purpose of Persistance is to make

data persist from one running of an application to the next running
of 
the same application.  If Persistance serializes the data
it persists for efficiency reasons (rather than say just doing a RAM 
dump and restore), that is an implementation detail, so to speak.  If

my definitions seem circular, it is because I think my usage of the 
terms (capitalized) is in line with standard usage of the terms.  

At any rate, I do NOT want to quibble over terms, I want to iron out 
what distinctions are relevant *for the purposes of creating and
using 
libraries*.  We can label the categoriesin any generic fashion that 
suits our tastes.

>But I agree there is a need to separate plain serialisation from
data 
>conversion/formatting/filtering. With XML, for example, the intent
is not 
>so much to save and load the data (there are more efficient ways of
doing 
>that), but to work on the data in its XML form with XML tools.
>
>It is maybe worth identifying another possible purpose, that of
reporting 
>or logging, where the serialised output is meant to be read by a
human. 
>For this it may not be necessary to have input archives, just output

>archives.
>
>For the sake of concreteness, I suggest "serialisation",
"conversion" and 
>"logging".
>
So the goal that I intend to achieve with "Persistance" you intend to

achieve with "Plain Serialization." As explained somewhat above, I 
think that plain serialization has a sufficiently different use case 
that we should have a seperate library for it.  Also, I don't want to

pigeonhole plain serialization to using a serial back end.

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,
and so we need to allow them to easily write their own
transformations 
that can be plugged into a serialization library.  I feel that it is 
more important that we work out what *types* of transformations to 
support rather than which specific formats (except as example for a 
given type).

>>2. Careful description of scope. Answer questions like: 
>>     * Is this a persistence or serialization library?
>>    
>>
<snip>

Given the terms Dave was using when he asked this question, then your
answer could be summed up as serialization :)  Anyway, I agree;
that's 
what I said in my original post.  With one caveat, though. I think
that
plain serialization (your term) should be explicitly *not supported* 
and defer that use case to a safer, more airtight approach with a 
persistance library.

Thanks for your input!  Cheers-

Augustus

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com