Re: [boost] [Serialization] Future of Boost.Serialization

Subject: Re: [boost] [Serialization] Future of Boost.Serialization
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-02-15 04:53:56

On Mon, Feb 14, 2011 at 8:17 PM, Daniel Larimer <dlarimer_at_[hidden]> wrote:
> On 2/14/11 1:36 PM, "Germán Diago" <germandiago_at_[hidden]> wrote:
>
>> I think that Boost.serialization library is a good library, but if it
>> were written nowadays,
>> it would be done in another way. I think that the correct way when
>> c++0x is implemented
>> Â with some trait that identifies the members that you want to serialize, and,
>> after that, return an in-memory object, like a string. Having the
>> information provided
>> by those members, you could implement generic
>> and custom serializations: binary, json, and whatever, without having
>> to code a special-purpose
>> format for your specific library. This way we can make libraries useful
>> to more people.
>
> What do those who are more experienced with Boost.Serialization have to say
> about the future of that library? Â What direction is Boost.Serialization
> going?

I certainly am no expert on Boost.Serialization but I've written
two or three serialization/marshaling utilities and I've played
a little with boost.Serialization in the past.

>
> It seems to me that Boost.Serialization is only compatible with itself and
> even though it can 'read/write' to/from a XML or even a 'json' file, it
> gives you very little control over the resultant structure of the file,
> because it throws in version info, object graphs, etc. Â So attempting to
> implement a JSON RPC built on Boost.Serialization is difficult if you do not
> control both sides of the RPC.
>
> Another example would be implementing a binary RPC protocol that must
> communicate with an embedded device that only supports C. Â It would be very
> difficult to craft specific byte streams from structs without knowing the
> internals of Boost.Serialization. Â It appears that the only option at the
> moment is to implement your own Archive.

As I've already written on the other thread, something like this can
be completely reflection-based and the Mirror library will implement
a manipulator generator tool similar to the already available factory
generator. The user will have to provide special templates saying
how to handle member variables with 'atomic' types like int, float,
string, etc., how to (generically) handle structured types and containers,
and how to handle enums. The generator then will create a manipulator
based on the reflected meta-data and the user specific code.

There are basically two things I need to resolve before starting
the work on this:
1) some good abstraction for container reflection
2) object tracking

Matus