Scott Woods <scottw <at> qbik.com> writes: anything else.
If I could reword this slightly
I hope I never said that blocking functions were inherently bad or in "poor style".
No that was me I think :-) But I did perceive you as criticizing RPC clients for blocking while the server is processing their request.
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.
To me that two-way relationship is a little fragile, precisely because it's two-way. The advantage with the server/client model is that both parties know their roles, and you don't have to invent protocols to decide who should say what and when. You can implement messaging as servers sending oneway RPC's to each other, right? On the other hand, you can also implement RPC's on top of a messaging infrastructure. To me the first option looks simpler, both for the user (and the library implementer...). Not everybody wants to be a server.
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.
At the end of the day, I guess even a RPC server is just... sending and receiving messages. It all seems to boil down to the same thing, IMO the question is more about what kind of an abstraction you want to present to the user, either client/server or server/server. Personally I'd rather go with client/server.
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.
As you guessed I'm leaning more to the procedural side :-) But a good RPC library can cater to both camps I think. What do you see as the main advantage of basing everything around messaging, as compared to sync/async/oneway RPC's? /Jarl.