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