RPC Technologies

[Nathaniel Mishkin]

In article <140558 at sun.Eng.Sun.COM>, cmcmanis at stpeter.Eng.Sun.COM (Chuck McManis) writes:
|> I've heard the argument that it is "more efficient" for NCS to maintain
|> that state than it is for the kernel to maintain that state but state
|> is state. Even the ECMA people recognize this is a better way to
|> implement these semantics and specify TP4 as the underlying transport
|> for ECMA 127.

The day I start basing performance decision decisions on statements of
international standards organizations...  Well, you get the idea.

This whole "conversation" has gone on so long I can't remember whether
I made this point or not yet:  The issue has nothing to do with NCS's
implementation or the fact that it's "based on datagrams" or whatever.
The right way to think about what we did was simply that we designed
a virtual circuit protocol with the knowledge in hand that RPC was going
to be layered on top of it.  Doing so lets you better "piggyback"
information.  For example, the initial "data" for the "connection" can
be passed in the connection "open" message.

|> And your entire argument goes up in smoke. You see, someone _did_ say
|> that to C compiler writers, and they _did_ say *I must have this* because
|> some people _do_ know better and they _don't_ want to have your choices
|> forced down their programmatic throat. In the C compiler arena these
|> are called "#pragma" statements and at least one C compiler I know of
|> lets you completely redefine the way in which calls are made by the
|> compiler! And guess what that's in the standard too!

"#pragma" may be in the standard, but the particular things you can SAY
in a pragma are not in the standard.  Good luck if you use a pragma
to express some semantically relevant intent and you try to take your
code to another system/compiler that doesn't know about that particular
pragma option.

|> >I have always taken the RPC model as a way to help those programmers by
|> >hiding the network from them -- to relieve them from having to understand
|> >things that you and I understand only too well. ...
|> 
|> I like it, a shade on the "I know better than you" side but it shows
|> a strong conviction. Would you feel better if we put using "connectionless"
|> transports in the advanced section of the manual? I think everyone can
|> agree on the goal, but most programmers disagree with the philosophy
|> that "we will decide what is best for you." That reeks of proprietaryness.

Well, what can I say?  I clearly am not going to disagree with the point
that it's bad to have a "we know best" attitude all the time.  It's a
matter of degree.  When I call read(2), I don't get to control how long
the data stays in the buffer cache and I don't get to control how many
blocks are read ahead.  Does this reek of proprietary-ness or is it
just "doing the right thing"?

                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin at apollo.hp.com
                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin at apollo.hp.com