Hey Sohail!
Sohail Somani
... In any case, for all networked applications, both ends need to fully agree on a protocol whether or not they are using the same s11n library.
Definitely true - but that's true of anything using any form of serialization (or marshalling or other appropriate term). Let me clarify or summarize my thoughts in this e-mail thread - here's one of the statements Robert makes in the B.S11N rationale: "This library will be useful in other contexts besides implementing persistence. The most obvious case is that of marshalling data for transmission to another system. " Since that fits exactly in the area I typically work in, and I'm starting to do some B.Asio work, and it's germane to other current Boost discussions (binary I/O streams, RPC libraries, various networking projects), I'm trying to see whether / how B.S11N fits in. If both sides use B.S11N with the same archive, it's going to work just fine (given an appropriate network header / wrapper, as demonstrated by Chris K in B.Asio). But if only one side uses B.S11N, what are the implications? What I'd like is something similar to (simple example): struct Track { Gps loc; // two floats Dir dir; // int std::string trackId; std::vector<int> iffData; }; template<class Archive> void serialize(Archive & ar, Track & t, const unsigned int version) { ar & t.loc; ar & t.dir; ar & t.trackId; ar & t.iffData; } Other app domain classes would / could have more complicated serialization semantics. Now the archive should / could be selectable by different layers of the app / framework, and not ever disturb the code above, so for example you might send / receive using: 1. B.S11N text archive (other side has same) 2. b.S11N XML archive (other side has same) 3. A binary archive (other side does not use Boost) 4. A text archive (other side does not use Boost) I would hope the network "on the wire" protocol could be implemented through a B.S11N archive. The above example code could be easily sent as XDR or CDR (for binary), or a simple text protocol with the other side able to directly extract the data into a similar struct. The full range of B.S11N capabilities are typically not implemented in most "low level, on the wire" protocols, so constraints would be present. But it would allow a nice separation of application domain serialization code from the mechanics of the serialization archives. Maybe another way of stating my thoughts - as I'm just now learning the basics of B.S11N, I'm trying to understand the mapping of the app domain serialization logic to the underlying B.S11N archive code, and the associated implications. If B.S11N is not the best general-purpose library for my needs, I want to understand why and what a good general-purpose design would be. In particular, application domain code should not know or care about the underlying protocols used for networking or file I/O. Cliff