Re: [boost] [rpc/marshal] prototype rpc / marshal library using asio and serialization (and futures in the future?)

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-04-30 14:48:31

Hi Jeff, Peter, Rene,

Thanks for the thoughts and suggestions.  I guess the consensus is
that there is use for both sync and async aspects, and both should be
in an RPC library that takes itself seriously, with an emphasis on
making sure the user is aware of the nature of remote calls and has
tools to deal with any problems that might come up.

I'm currently threading through the end-of-semester quagmire, and
working on a couple conference papers, so it will take me a bit to
flesh out the next iteration of the library, which I was hoping to
support async calls through futures, and hopefully a beginning of
intelligent error and exception handling.

Anyway, getting this started was in a way a warm up for the signal
library GSoC project... some of the concepts are related, and for me
it seems like the best way to reach a destination is to aim about 60
degrees to the side :-)

Finishing it, of course, will be a lot more than a "warm up" :-)

Thanks again,

Stjepan

On 4/29/07, Jeff Garland <jeff_at_[hidden]> wrote:
> Rene Rivera wrote:
> >  From my own experience (I have my own RMI/RPC framework), I can say
> > that I agree with Peter.
>
> Actually I didn't think Peter and I were disagreeing :-)
>
> > I have both sync and async calls and both are
> > beneficial. It is usually a matter of context which one you use. For
> > example I use sync calls during the connection process since in that
> > context nothing else makes much sense.
>
> Which is reasonable assuming 1) you make a connection up front independent of
> the actual RMI/RPC, 2) you don't have a high latency network (eg: over a
> satellite hop or two), 3) you control the machines used by both client and
> server, etc, etc.  Of course, you probably don't wait forever for a connection
> to complete, either, so I assume there's at least a built-in timeout...maybe
> even a disconnect/reconnect strategy.
>
> > Almost everywhere else I use async calls.
>
> Good choice ;-)
>
> Really I think there's no disagreement here.  I don't have a problem with an
> RPC option that includes sync behavior.  I just don't want Stjepan to go down
> the path of building and all sync RPC solution b/c I don't think that's going
> to fly.
>
> Jeff
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>