Boost logo

Boost :

From: Scott Woods (scottw_at_[hidden])
Date: 2007-04-19 21:45:30

----- Original Message -----
From: "Stjepan Rajko" <stipe_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, April 19, 2007 10:53 AM
Subject: Re: [boost] Marshalling library

>> 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
> starts).
> 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.

How's this for a 1st cut breakdown;

* asynchronous socket manager (definitely a thread or threads, might be in
* asynchronous RPC manager (probably a thread) with a sync interface for
application access
* synchronous application thread(s)

Something like this would deliver what you are after, if in a more
cumbersome way
than what you might have been thinking. Maybe some magic is created if it
also caters
to needs such as the following;

* deriving from the base socket manager to create an optimally fast FTP
* ability to communicate with two RPC servers, one running a high-speed
proprietary encoding (Boost!)
to a local server the other running good old Sun RPC (is that XDR encoding?)
to some remote legacy
box, the location and associated encoding being transparent to the caller.
* ability to switch the local server encoding between fast and readable
(i.e. debug vs release)
* facility to develop a monitoring and control tool for a socket manager.
* ability to instantiate both a base socket manager and the dedicated FTP
server in the
one executable, each one taking ownership of an accessible interface or port

While these requirements might seem contrived, the circumstances are not so
unrealistic. If
you tackle the intiial goal (RPC) but deliver a collection of types and
objects that provides
for the needs above then I really think you would have something. Its the
decomposition into
the useful pieces; that's the intractable bit. If you get it right then its
easy to reshuffle into
new arrangements such as those above.

Hope that explains my position a bit better. The solution is not obvious to
me and thats
probably been apparent in my messages.


Boost list run by bdawes at, gregod at, cpdaniel at, john at