Boost logo

Boost :

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
>> Augustus Saunders in
>> I
>> that Robert didn't like those definitions, but they resonated
>> 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
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
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
being stored intrinsically cannot be transparent--somebody has to
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
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
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
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
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
>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
>that), but to work on the data in its XML form with XML tools.
>It is maybe worth identifying another possible purpose, that of
>or logging, where the serialised output is meant to be read by a
>For this it may not be necessary to have input archives, just output

>For the sake of concreteness, I suggest "serialisation",
"conversion" and
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
you feel are important. Well, as I think the original discussion
showed, people have a wide variety of desired output types and
and so we need to allow them to easily write their own
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?

Given the terms Dave was using when he asked this question, then your
answer could be summed up as serialization :) Anyway, I agree;
what I said in my original post. With one caveat, though. I think
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-


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

Boost list run by bdawes at, gregod at, cpdaniel at, john at