----- Original Message ----- From: "Jarl Lindrud" <jlindrud@hotmail.com> [snip]
If this message is useful to you maybe its to help decompose the design and implementation of RPC. If the internals of your RPC were totally message-based and state-driven then perhaps everyone would be happy. Well, I would be
[snip]
I agree with you that its poor style to have a client block while waiting for a reply. In fact, blocking functions are almost always poor style, whether you're dealing with network communications or anything else.
If I could reword this slightly :-) I hope I never said that blocking functions were inherently bad or in "poor style". When I think of all the banking applications written using CORBA (i.e. RPC) I dont quite feel bold enough to question the efficacy of choosing that toolset. Selection of an RPC-type mechanism for development may be a justifiable project decision. Development and maintenance may be simpler at the cost of "high-end" user feedback (e.g. wait-cursors, progress bars). Of course the decision may be wrong and the brunt of the error may be borne by the software team but that is all separate to the issue of "is blocking good or not". tioned previously in this thread as well, that it would be unwise to
place remote function calls behind local function call semantics. If the remote call is blocking, then I agree, but the problem is that the call blocks, not that it's a remote call looking like a local one.
Hmmmm. I suspect that procedural programming still has strong influence over the views you express. Which does not make them wrong :-) I'm not sure I can say anything useful here. Messaging allows for a responsive, two-way relationship between software components, i.e. either party may initiate a phase of activity within the wider relationship. RPC prescribes a simpler relationship and is consequently more constraining, but still perfectly justifiable. Messaging is appropriate (i.e. a necessity) at the level of actual network sends, while RPC (over a messaging lib please) may be a reasonable model for development of certain applications. In a messaging world it would not be unreasonable to hide a blocking library call behind a messaging interface. Is that now a non-blocking function?
I'm pretty sure I can make my library function well both in non-blocking and blocking modes, but it needs to be designed from the bottom up, with that in mind, as you're saying. I'm going to be redesigning it anyway, so hopefully there will be some opportunity to get it right.
If I have managed to contribute something then I feel great. I would be very interested to see your re-worked boost-ified rpc (esp. the internals ;-). Cheers.