From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-04-17 17:43:06
Hello Hans,
On 4/16/07, Hans Larsen <hans_at_[hidden]> 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