So I believe that your requirements conflict in a fundamental way with those explicitly state for the serialization library. I suspect that it's not a good solution for you.
That's very possible. Although never explicitly stated in the Boost.S11N docs, your e-mail statements imply that B.S11N is not usable unless both "sides" (reader / writer, sender / receiver) are using B.S11N. Otherwise the non-B.S11N side must know the intimate format and protocol of the metadata added by B.S11N, and would be subject to changes in the internal protocol, pretty much making it a non-usable maintenance headache. I have no problem with this constraint on B.S11N, although it does limit it's applicability (while providing more capabilities for the "save and restore object state" type of applications). I now better understand why some of the networking people have been discussing a completely separate "marshalling / unmarshalling" library to handle that need (rather than consider how to integrate with B.S11N). Much of my day job is designing and implementing distributed processing systems, between heterogeneous systems, where any or all of the following can vary: platform, OS, compiler, endianness, language, and third-party libraries. I was hoping that an application could write one (B.S11N) serialize function and instantiate it with a variety of (B.S11N) archives that would allow control of the object marshalling and unmarshalling, to the degree that an application could interface with another application not using B.S11N. The capabilities allowed for this kind of usage are obviously more limited than what B.S11N allows for object serialization and re-instantiating. Looking at the B.Asio example code using B.S11N, there's an assumption that both sides of the network pipe are using B.S11N. The text archive string is wrapped with a header (basically the size of the string), following a very typical networking approach (read the fixed size header, which contains the size of the rest of the message, then read the rest of the message until everything arrives). All of the "message data" contents are opaque to the network / ASIO plumbing of the example code, and the actual object serialization and deserialization is left up to the B.S11N archive code. I welcome any corrections to my assumptions, characterizations, or implications ... :) Cliff