Hello Hans, On 4/16/07, Hans Larsen <hans@poltras.com> wrote:
On 17-Apr-07, at 1:07 AM, Stjepan Rajko wrote:
Yeah, what I have right now in the signal network library prototype is a little pair of objects which serve as a trans-socket signal. One of them receives a signal / function call locally, serializes the arguments via Boost.Serialization into a string, and sends the string through an asio socket. On the other end, the other object receives the packet, de-serializes it, and generates an identical signal/function call on that side.
That's exactly what I had in mind.
Cool. The code is available from: at http://dancinghacker.com/code/signet/ Feel free to use it :) The current code (which allows you to send a specific function call over the socket) could be used with the marshalling library sketch by making the "reg(call2_5_6)" or "reg(2, call_5_6)" call over the network. While this would work it's inefficient because it serializes/deserializes twice (once to construct/deconstruct the call2_5_6 string, for example, and once to construct/deconstruct the network packet). So, I'll work on separating out the socketing functionality so it can be used separately by either the current over-a-socket signal sender/receiver pair, or the RPC sender/receiver pair. Also, the current receiver is synchronous which is not very useful - I still need to add an asynch version.
<snip> [2] We'll have to find a way to identify in, out and in-out parameters (return parameter included). I'm working on a way right now.
Just an idea, but perhaps as a default behavior we can use the parameter types to deduce what can be used to return a value? For example, any parameter that is a non-const reference or pointer to non-const automatically gets marshalled back. We can then offer functionallity to override this default behavior (i.e., don't marshall anything back, or only marshall something specific). Stjepan