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@crystalclearsoftware.com> 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