From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-04-17 01:07:30
On 4/16/07, Scott Woods <scottw_at_[hidden]> wrote:
> Just a bullet-point review of your example of marshalling in case
> I'm missing something;
> * a register of return type+parameter list, keyed on small, unique integer,
> * generate portable image (string) of a call, i.e. "marshall",
> * call the registered function using one of several available conventions.
Yep, you got it. That's it so far :-) The key is templated so
theoretically it could be something other than an int (I used int
because that was in the original example by Hans).
> > In any case, I'd be interested in getting some marshalling into boost
> > because that allows for distributed signal networks that can not only
> > pass signals from one computer to another but also execute RPCs.
> That would be inherent, i.e. the ability to execute RPCs is a freebie
> once distributed signaling is working? I dont mean literally, more that
> an RPC would be achieved through an exchange of a particular set
> of signals.
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.
Marshalling would work the same way except the packet would also carry
the function id/key, and on the other end a function would be called
from a function registry.
Neither of these mechanisms handle returning of the data from the
function call right now, and even if they did I'm sure there's a lot
of other marshalling/RPC issues to be considered... not an expert.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk