From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-04-17 17:43:06
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:
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
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.
>  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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk