[boost] Re: Re: Serialization library - submission #5 and request

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-09-14 01:31:37

Vladimir

Well, much to my amazement, we seem to be making progress.

First I would like to expand a little on the "Describe" issue

>1. Will you mind if anybody writes a 'describe' based wrapper and 
>submits it.

Of course anyone can submit something that builds on the serialization
library.  Heck, the serialization library builds on all sorts of other boost 
stuff.  I may not have interest in such a facility myself but I certainly
don't insist that no one else have interest.

>2. Will you be willing to tweak your library if 'describe' 
>implementation will not be 100% orthogonal. I think there might be some 
>problems with making both describe and save/load work.

I would hope that describe would be 100% orthogonal.  If not, then it
would have to be looked at.  In general I would not see any problem
where the library is "too strong" in that in imposes unnecessary
requirement.  I have gone to great efforts to avoid this from happening.
Factoring our archive.hpp and stl.hpp were the result of exactly this
kind of problem.  It made the "serialization" part much smaller and
permited it to be more open ended.

Its interesting to note that an almost identical situation has arisen
already.  In trying to find a general solution to exception safety
I created demo_shared_ptr.cpp.  I came to believe that to 
implement serialization of shared_ptr (a very, very, compelling concept)
I needed access to a private member of shared_count.  I contacted
Peter Dimov about this but I havn't been able to convince him to change  it.
So for now I've just left it as an example in the serialization package.
Naturally I hope to convince him to change his mind in the future 
(if and when serialization gets added to boost) . If the libraries are well designed,
this kind of thing will happen only occasionally and it should not be
a long term problem.

So basically, I have no objections to tweaking the library to permit
it to be used more widely.  Note this is quite different to adding
features that I believe should be maintained separatly.  Of course
this is easier to agree upon this in the abstract ratther than
specifica cases but all in all I consider
myself a pretty easy going and reasonable person and would
derive great satisfaction in seeing the library used a building
block for unforseen applications.  I already see it as useful
implementing Remote Procedure Call argument passing.

>If yes, then I withdraw the 'describe' issue.
I would call the above a 'yes' mostly.

>XML format would require member names, and this is another issue which 
>will require support from your library.

Now on the the real topic that interests me as it relates to "Describe"

I see the following future for serialization.  Read ==> as "implemented with"

XML export/import ==>
        C++ reflection ("Describe") ==> // associates names/variables
                boost 1.29
                ?
        serialization ==>  // "flattens and unflattens" structures"
                boost 1.29 ( type_traites, etc)
                stl
        xml_archive ==>   // converts to/from xml text
                basic_archive =>
                        stl
                        std::streams ==>
                                std::steambuf

So that is where I see things fitting.  This is pure speculation, please don't ask
me to defend this now.To summarize, "Describe" is really too important,  interesting
and intricate to be shoehorned into serialization. It really deserves
its own module/library.

Variable names required for XML would end up as part of C++ Reflection ("Describe").  

Besides the above I would like to see streambuf adaptors for compression
and encryption.  For my personal use serialization + these adaptors would be ideal.
Of course these would be very useful without serialization as well.  Anyone want
to volunteer for this?

I am still thinking through the issue of global vs archive registration
and I expect I will have more to say about this later.

Robert Ramey