Re: [boost] Marshalling library

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 
asio)
* 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 
server
* 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 
range.

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.

Cheers.