Re: [Boost-users] [serialisation]Portable Binary Archives, distributed processing, a small comment on B.Asio

From: Cliff Green (cliffg_at_[hidden])
Date: 2007-06-27 16:30:28

> 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