Re: [boost] Re: RPC library

From: Scott Woods (scottw_at_[hidden])
Date: 2005-03-08 20:14:15

----- Original Message -----
From: "Jarl Lindrud" <jlindrud_at_[hidden]>

[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.