🚀 go-pugleaf

In article <1990Aug9.180750.5568@athena.mit.edu>, pae@athena.mit.edu (Philip Earnhardt) writes:
|> In <4bc8788d.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin)
|> writes:
|> >At worst.  If the demand appeared to exist, I suppose we could document
|> >the interface between the authentication module and the rest of NCS.
|> >This would allow people to write authentication modules without having
|> >the source to NCS.
|> 
|> I'd rather not beat a dead horse, but ... 

Me neither.

|> this would then allow customization by application developers ...
|> clearly a limited form of customization (as the 'RPC protocol' would
|> presumably be left intact).

I think the word "limited" is key.

|> Which leaves open the question of what other sections of NCS may need
|> to be 'customized' by the end user.  I do not believe that you would
|> claim that you have thought of all possible applications of NCS and
|> therefore you could not have included all things that the users may
|> find neccesary.  For this reason, Netwise-style customizations, while
|> not allowing all possible customizations, certainly allows the users
|> a great deal more flexibility in building their applications.

I won't deny that customization gives programmers more options.  We
obviously have philosophically different opinions about whether increasing
the programmer's options in this way is ultimately a good thing, i.e.,
whether it yields a system that makes it easier to write and maintain
correct distributed applications or whether it would be better to learn
(admittedly, over time) what the programmer's real needs are an address
them in a coherent way in future versions of the product.

|> >>But again, you folks are constraining the choices of your customers. 
|> >
|> >As does the C compiler writer who chooses to make his compiler save
|> >registers on ALL procedure calls, not just on those generated by a
|> >compiler targeted for a particular hardware architecture.
|> 
|> This is a very odd defense.  To defend constraining your customers
|> by pointing the finger at other folks who have done so in the past
|> is ludicrous.

I guess I don't see why it's an odd defense.  I'm not pointing my finger
at any one else.  I thought I was making a humorous analogy.  I guess
I mixed up my complaints about Netwise's lack of (what we call) "transport
transparency" (i.e., ensuring constant call semantics regardless of what
transport you happen to be running RPC over) with my complaints about
customization.  The analogy was that building a system that sometimes
yields one call semantics and sometimes another (depending on what
transport the application was running over) was like having a C compiler
sometimes preserve registers (that contains useful values) across calls
and sometimes not (depending on what hardware architecture the C compiler
was targetted for), yielding different program behavior.

I'll try to re-draw the analogy to apply to customization.  If someone
said to a C compiler writer:  "Hey look, I know what I'm doing and I
don't want you to save registers when I make this call; give me a way
of telling the compiler to not save registers", I think people would
argue that that kind of customization is a bad idea.

|> And if one of your customers chooses to use NCS/TCP, what will declaring
|> a procedure as idempotent do for them?  Specifically what optimizations
|> will be applied?

I'm aware of none that can be applied.  Is this a problem?  The programmer
states an invariant fact about his procedure.  Seems appropriate.  The
underlying system may or may not be able to take advantage of this fact.

|> >We've been over this again and again.  People don't want "CL and CO RPC".
|> >They want RPC.  They want to make certain performance tradeoffs made
|> >available to them.  NCS addresses this desire in an appropriate way.
|> 
|> I am not sure how you can make such a sweeping generalization. Is
|> this the result of some HP marketing survey or do you believe that
|> just by saying it, you can make it true?

The day marketing can get me correct answers to questions like this will
be a happy one for me, believe me.  Unfortunately, my experience has been
that it's hard or impossible to answer these questions by survey.  Sometimes
one just applies one's own engineering sense and more limited interactions
with application builders.

All I know is that it has always been my impression (reinforced, BTW,
by things that marketing people tell me) that there's a large body of
programmers to whom "network programming" is a daunting prospect.  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 am trying to develop
a system where, as the system evolves, programmers have to know less
and less about the network.  In service of this goal, I try to make it
the case that the system doesn't require me to talk about "CL vs. CO"
in describing the system to its users.

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

In article <4c2d2946.20b6d@apollo.HP.COM> (Nathaniel Mishkin) writes:
>I guess I don't see why it's an odd defense.  I'm not pointing my finger
>at any one else.  I thought I was making a humorous analogy.  I guess
>I mixed up my complaints about Netwise's lack of (what we call) "transport
>transparency" (i.e., ensuring constant call semantics regardless of what
>transport you happen to be running RPC over) with my complaints about
>customization.  The analogy was that building a system that sometimes
>yields one call semantics and sometimes another (depending on what
>transport the application was running over) was like having a C compiler
>sometimes preserve registers (that contains useful values) across calls
>and sometimes not (depending on what hardware architecture the C compiler
>was targetted for), yielding different program behavior.

Fortunately for most programmers they specify "connection-oriented" and
get the exact same behaviour as NCS's connection oriented dressing over
most other transports. You are absolutely correct that if the programmer
say's "I'll take _any_ transport." The one they get will always work
but may not maintain strict procedure call semantics. And yet, if they
as for connection oriented transports, they will always get reliable
at most once semantics, unlimited argument size, and all those other
nice things that one may want at the expense of keeping some state 
of the connection around. 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. 

>I'll try to re-draw the analogy to apply to customization.  If someone
>said to a C compiler writer:  "Hey look, I know what I'm doing and I
>don't want you to save registers when I make this call; give me a way
>of telling the compiler to not save registers", I think people would
>argue that that kind of customization is a bad idea.

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!

Your belief that your customers don't want to be able to customize
their network applications is unfounded. There are people in both
camps. There always will be, NetWISE and Sun have always tried to cater
to both because they are all customers.

>All I know is that it has always been my impression (reinforced, BTW,
>by things that marketing people tell me) that there's a large body of
>programmers to whom "network programming" is a daunting prospect.  

This is a tautology. You could just as easily say that there are a large
body of _people_ to whom "programming" is a daunting prospect. But
that doesn't justify making BASIC the only programming language.

>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 am trying to develop
>a system where, as the system evolves, programmers have to know less
>and less about the network.  In service of this goal, I try to make it
>the case that the system doesn't require me to talk about "CL vs. CO"
>in describing the system to its users.

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.
Think of it like a car manual. The first few pages start off with how
to start the car, shift gears and turn on the headlights. By the time
you get to the end of the NetWISE manual you can swap out carburetors
and reset the timing for maximum performance. Halfway through your
manual it says "no serviceable parts inside, go see your dealer." Sorry
but that doesn't cut it.


--
--Chuck McManis						    Sun Microsystems
uucp: {anywhere}!sun!cmcmanis   BIX: <none>   Internet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"I tell you this parrot is bleeding deceased!"

In article <140558@sun.Eng.Sun.COM>, cmcmanis@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@apollo.hp.com
                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com