----- Original Message ----- From: "Stjepan Rajko" <stipe@asu.edu> To: <boost@lists.boost.org> 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.