Boost logo

Boost :

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

Scott Woods <scottw <at>> 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

> 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at