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? 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. Dan