
On Mon, Feb 14, 2011 at 8:17 PM, Daniel Larimer <dlarimer@gmail.com> wrote:
On 2/14/11 1:36 PM, "Germán Diago" <germandiago@gmail.com> 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