Re: [boost] [Serialization] Proposal for TR2

Subject: Re: [boost] [Serialization] Proposal for TR2
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-11-15 00:25:13

Beman Dawes wrote:
> On Mon, Nov 14, 2011 at 12:25 PM, Ruediger Berlich
> <ruediger.berlich_at_[hidden]> wrote:
>> Dear Robert, dear all.
>>
>> from what I understand, Boost.ASIO has been proposed for TR2 quite a
>> while ago. Since I use ASIO and Boost.Serialization quite a bit and
>> feel that both strongly benefit from each other (and not only ASIO
>> -- see e.g. Boost.MPI), are there any efforts to make
>> Boost.Serialization part of TR2 ?
>>
>> We live in the era of cloud computing and networked execution.
>> Without this facility, C++ will have a hard time to compete. And
>> Boost.Serialization is established and mature (thanks, Robert!).
>
> My guess is that the C++ committee's Library Working Group (LWG) would
> be very interested in a proposal based on Boost Serialization.

I'm incredibly flattered that anyone would even suggest such a thing.

However I've alway felt that this would be a bad idea.  I have two
sets of reasons for this.  The first set pertains to serialization as
implemented in my library.

It wasn't really designed formally enough.  I never really understood
the concept of concepts until after I got everything (especially the 
documentation)
done.  This shows up in the library in lot's of ways - the large number
of fixes I had to implement over the years.  A series of ambiguities
which show up from time to time.  A few archive breaking changes which
have caused much pain.  But basically, the interface of the library
hasn't been specified unambiguously enough to be basis of any sort
of standard.

The other reason is a lot more interesting.  I made a large number of
decisions about what "serialization" means.  Amazingly to me - most
people just accepted those decisions (but not all).  Here are a few.

a) the library doesn't define any i/o format.  It is very closely tied to
C++ and in general can't be used by other languages.  For some
people that makes a non-starter.  See google protocol buffers.
Peter Dimov raised the very point from the very beginning - and
all I can say is that not everyone agrees that serialization is what
I say it is.

b) I implemented the concept of tracking so make archives more
efficient and handle pointers.  But this really conflicts with the
usage of serialization for things like the MPI library.  The MPI
library uses the skeleton and doesn't track addresses.  So this
works great for using the same buffer to send and resend
data blocks.  This is very different than the archives which
track the data.  No one has ever noticed this.  The serialization
library interface it compatible with either one - ambguity again.

c) I had the vision that it would non-intrusively handle abstract
base class pointers.  To me this concept was indispensable and
crystal clear.  Implementing such a thing turned to be very difficult.
And just when you think you've done it, something else comes up.
In particular, there's the issue of when part of the serialization
is implemented in a DLL.  It's very hard to make a huge program
(where it is most useful) without violating ODR and introducing
ambiguites in the program.

Make the definition of serialization suffiently rigorus would be
a big undertaking.  Change  would ripple through the implemention,
and create a lot of work - and break current archives.  Mostly
it's the scale of work require which would disuade me.

Actually, I'd personally prefer to spend more time making some
archives to deal with editing.  for example qt_i/oarchive where
one would copy do something like

window w;
qt_oarchive oa(w);
oa << my_data;
... edit the window elements
qt_iarchive ia(w)
ia >> my_data;  // changes.

Basically the serialization library is the truimph of development
over design (from a description of the IBM selectric typewriter)
A successful strategy perhaps - but not a good basis for a formal 
definition.

Robert Ramey

> --Beman
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost