From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-04-18 18:53:24
On 4/17/07, Scott Woods <scottw_at_[hidden]> wrote:
> I now have a wish-list for tools
> and techniques I might consider for marshalling in the future. Here are a
> * single definition of external representation (i.e. serialization) for
> persistence and network messaging purposes
> * multiple encodings (e.g. readable, fast or secure)
> * purely async software at the lower levels, i.e. only an application thread
> may block on a sync RPC
> * multiple program and threading models (e.g. simple server like an FTP
> server vs a complex program that initiates
> and accepts multiple connections with different encodings and protocols)
> * formalized protocols, i.e. an RPC protocol might have CALL, RETURN and
> EXCEPTION entries.
> * object-based message routing (e.g. a (local) object originates a message
> and a (possibly remote) object is the target)
> * integration with standard protocols and encodings
> The scope of this list get daunting quickly. What is the scope for you guys?
My personal needs are pretty basic - just making a remote call and
getting the results back would cut it. In terms of designing a
marshalling framework, I'd propose separating out as much
functionality from threading, network, shared memory, and other
issues, and sticking to the actual function call and execution (for
What I'm hoping is that things can be designed so that other Boost
libraries can transparently address these issues through existing
functionality. For example, the readable/fast encodings can be used
by allowing the choice of either binary or xml (or text) serialization
archives offered by Boost.Serialization. A secure channel can be
established by using an SSL asio connection, etc.
Your wish list encompasses a lot of things to keep in mind - let's see
how many we can map to existing Boost functionality.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk