Re: [boost] Questions on Serialization

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-24 10:32:42

This raises the question of what to do in the following circumstances.

a) person X requires serialization for  library Y
b) It doesn't currently exist and the current library maintainer has not 
made it.
b) so he writes it and likes it.
c) he wants to submit it to boost

Questions that arise:

a) His addition will included a header - where should it go.
    i) My current preference is boost/Y/serialization.hpp
    ii) On the otherhand, the ones I personally did - shared_ptr and some 
others have been put into boost/serialization/Y.hpp.  This also applies to 
the STL serialization - since there is not boost/stll/... in any case.
b) He should include tests.  But where should he put them?  The current 
situation mirror that of the above.  The current method of making the 
library maintainer responsable for making tests pass wouldn't attribute the 
responsablity to the appropriate party
c) Is any documentation necessary?  - where should it go?
d) Should such a contribution be subject to some sort of review.  This last 
is interesting to me.  In the past I received an implementation of 
serialization for boost::variant.  This is something I always wanted so I 
included it.  Then tests showed that the implementation wouldn't work for 
borland, msvc 6.x and maybe others.  The there was the "requirement, that 
the implementation depend only on the public interface.  The maintainer of 
boost::variant didn't participate.  The final implementation wasn't quite as 
efficient as I would have liked but I didn't want to start a drum beat to 
tweak boost::variant.  Adjusting the implementation to be as widely 
applicable as other serialization implementation - ie older compilers - 
turned out to be more time than I anticipated.  So I would like to see some 
"fixed points" be enforced - that is, that it meets the requirements that 
other serialization implementations in the library maintain.

Basically serialization for a library Y sort of lies in the intersection of 
the serialization library and library Y.

Robert Ramey

Martin Slater wrote:
>> library contains code to serialize "shared_ptr" types.  Should the
>> Serialization library contain similar code for every potential Boost
>> type, so should each type include the code?
>>
>> If the latter is the answer, then does:
>>
>>     class my_type {
>>         friend class ::boost::serialization::access;
>>         //...
>>     };
>
>
> I just ran into this again when I needed to serialize a
> boost::dynamic_bitset and with porting our codebase over to use 1.33
> bringing across the modification I made to boost::filesystem::path for
> serialization. If there is a chance that these will get incorporated
> into cvs I will go to the effort of writing and configuring test cases
> for them and submit them (I did submit sode and tests a long time ago
> for filesystem::path but unfortuantly they never made it in so I'm
> reluctant to do more unless there is willing by the library authors to
> have them). It seems there should be a concerted effort to get all of
> boost being able to serialise out of the box as it leaves the library
> as a whole feeling somewhat disjointed. I may have some free time in
> the near future so I could be persuaded to go through implementing /
> incorpating existing patches for serialisation for other boost
> libraries.
>
> cheers
>
> Martin