Re: [boost] Serialization Review Results

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2002-12-12 20:58:52

Dave Harris wrote:

>To me, "persistence" 
>and "serialisation" are at different levels of abstraction.
Serialisation 
>is one way to implement persistence. As such they do not compete;
they are 
>not mutually incompatible alternatives.

I agree, a symmetric serialization scheme could be used as one
backend to a persistence framework.  The point is to not take
requirements for a more general persistence framework and force them
onto serialization, or load persistance down with conversion issues
involved in many serialization cases.

>What is gained by excluding persistence, and/or the simpler kinds of

>serialisation (where source and destination are the same program
running 
>on the same hardware with the same compiler)? 

This is my reflection on our responsibility as library writers,
potential standards setters, and generally pionerring folks.  I
haven't had a chance to research (and if anybody else here has, they
haven't chimed in) whether or not we can build a (more) idiot proof,
more maintainable solution when all you want to do is persist some
application data.  Persistance is the simpler use case, although the
more challenging framework.  I don't want serialization to steal
mindshare before we have a chance to think through persistance.  When
I say "not supported," I don't mean impossible; I should have said
"not encouraged."  People will do it, sure.  But that doesn't mean it
should be the official, sanctioned way of doing things.  Right now,
not many applications (that I know of) use a general persistance
framework because they're all expensive and require special tools. 
So they wind up using MFC style serialization instead.  Now it's what
people are used to.  But I don't want us to pass up a chance to
improve state-of-the-art without a fight.  I mean, this is the home
of boost::mpl, boost::lambda, boost::graph, boost::spirit and other
amazing feats of modern C++ programming, right?

>> So far, you haven't provided a clear definition of serialization.
>
>Actually I agree with Augustus's, as far as I understand it, which
isn't 
>far. He seems to imply that serialisation does not need to bother
with 
>object factories or object lifetime management. I don't understand
how 
>that can be. 

Because serialization/deserialization happens at a specific point in
time.  Sure, you can build object factories that interface to serial
archives; in fact that's what peristance would do when using
serialization as a back end.  But you don't need a complex factory
system to ensure consistant application state on startup.  If you're
deserializing, you have a valid application state prior to
deserializing.  The point being, though, that serialization isn't
automatic; you invoke it.  I don't consider new and delete to manage
an object's lifetime like a smart pointer does.  After invoking new
or delete, there is no system tracking that object unless you make
one.  Same for serialization.

>I can't figure out whether UTD versioning belongs to 
>Persistence or to Serialisation. He says Persistence, but doesn't
that 
>make Persistence asymmetrical and involve it in non-trivial
transforms? 

I'm still not sure what UTD refers to.

>How can it be achieved by transparent meta-programming magic? I
doubt a 
>robust but transparent persistence mechanism can be built.

Maybe.  But in that case, it is a topic that should be left to the
OODB vendors and boost shouldn't bother with it.  But would you have
believed MPL or lambda possible two years ago?  Let's not give up
before we start.

>> Can you give an example of "containing the mess within the UDT?"

>I don't know what you think of this code - whether it horrifies you
for 
>being too low level or lacking in design foresight. It is my
practical 
>experience. Designs age, and the history accretes in the
serialisation 
>load routines. I hope that the boost library will be able to support
this 
>kind of evolution. I don't claim that code like this is the best
solution, 
>but in practice I have found it works.

Yes, but what I want to know is how you hope to change that code with
a serialization library.  Here's an important question that everybody
should be able to answer easily:

What should a serialization library provide that iostreams doesn't?

You could pretty much write that same code now with iostreams
replacing CArchive.  How is *any* serialization library going to make
your life easier than it is now?  I don't want to sound accusatory,
so let me rephrase: If you could have anything your serializing heart
could desire (that you don't already have), what would it be?

>I'm sorry for the length of this post, but now that I've written it,
maybe 
>you can tell me whether I want a persistency library or a
>serialisation library.

Maybe you don't want either one.  I think you just want a type
registration system and some object factories to facilitate using
polymorphic pointers with iostreams.

Cheers-
Augustus

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