Event-based I/O (was Re: VC protocols)

Ramin Firoozye (rpa@netcom.com)
Fri, 26 Aug 1994 10:39:22 -0700 (PDT)

>
> Daniel W. Connolly writes:
>
> Are we using different terminology for the same thing, or am I really
> confused about these terms? To my mind, HTTP _is_ an RPC protocol:
> the client sends a request, and the server answers. That's why I think
> it's overkill to use TCP.
>
> Or by RPC do you mean Sun RCP with their stubgen and all that? Or
> would DCE RPC, or ILU RPC do the trick?
>
> Could you elaborate on the distinction between RPC and messaging?
>
Uh... I confess I was actually being only a little facetious here. I don't
care much for religious debates, which is what RPC vs. messaging appears
to be turning into. By RPC I meant the Sun/DCE style RPC where you create
stubs, then call functions as if they are local and the underlying routines
take care of the rest.

There's a few messaging libraries out in the commercial world, mainly
used to connect to database servers for commercial client-server activity.
PeerLogic's Pipes is a big one there. Here, the model is more of a SEND/
RECEIVE activity. Asynchronous activity is the rule not the exception.
DCE is putting asynchronous calls into RPC, but unless your whole
application is event-driven, following a signal model is (IMHO) kind of a hack.

As for whether HTTP is RPC or not. We're definitely talking apples and oranges
here. HTTP is a an applicaiton protocol with high-level "opcodes" like
GET and PUT. Its implementation is completely unrelated to the protocol.
Most current implementation follow the READ/WRITE model. You can argue that
it would be more convenient to use the RPC CALL/RETURN model, or the
messaging SEND/RECEIVE model. It's really not a protocol issue. What I meant
in my previous posting was to replace the *implementation* of HTTP with
RPC calls (or messaging).

One advantage of the SEND/RECEIVE model is that the application can not
assume that it is going to immediately get a reply back. This forces
the developer to structure the application in such a way as to allow the
user to continue working while the RECEIVE activity is going on. Yes, this
is more complicated than doing a write and sitting there on a read until
all is done, but so was event-based GUI programming vs. prompt-based
command-line interfaces. Programmers were dragged kicking and screaming
into event-based programming, but everything seems to be fine now (:-)
What we really need is an event-based networking architecture that
takes care of all the underlying grunt work and just notifies the
program when something is done.

Cheers,
R.

-- 
Ramin Firoozye' 
rp&A Inc. - San Francisco, California
Internet: rpa@netcom.COM - CIS: 70751,252

--