[boost] Re: RPC library

From: Jarl Lindrud (jlindrud_at_[hidden])
Date: 2005-03-09 03:23:15

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.