🚀 go-pugleaf

In <4b69c9e1.20b6d@apollo.HP.COM>, mishkin@apollo.HP.COM (Nathaniel Mishkin)
writes:

> I understand your position and I don't know that there's much point
> arguing about the relative merits of customization.  We simply disagree.

This seems to be a bit of a 'back-off' from your previous postings ... are
we calling it a draw (i.e. yes there are dangers in customization and yes
there are instances where they are neccesary)?

> Async RPC is another one of those religious issues.  My religion says
> that they're a bad idea because they're hard to understand, represent
> an unnecessary new aspect in the computing model, and that one should
> use existing primitives for asynchrony (process) and communications
> (procedure call) together to achieve the same effect.  And in anticipation
> of the "but not all systems support cheap multi-threading" objection,
> I'll say (a) let's fix that and not introduce new features, and (b) it
> can't be that much harder to bring up a simple threading package than
                ^^^^^^^^^^^
                well in the RPC Tool case, it is infinitely harder as no
modifications to the base system were neccesary to support asynchronous RPCs.
The customizations that you find so objectionable make it fairly trivial to
support asynchronous RPCs.

> it is to bring up the async part of an RPC system that support async
> RPC and the return is much higher for doing the former than the latter.

I think that it is only hard to allow asynchronous calls when the RPC system
does not allow customization of its state transitions. The RPC Tool needed no
specific modifications to allow asynchronous RPCs, just some customizations to
the RPC spec to modify the state transitions. This allows the customer to 
decide which method of asynchrony is best for their application. If
asynchronous RPCs are 'bad', why expend the effort to add cheap multi-threading
to operating systems that don't currently support it? Also, multi-threading
support may or may not be easy to add to an existing system and it is 
certainly not easy for application developers to add into existing applications.
For this reason, it seems to me that offering asynchronous RPC within the 
framework of the existing RPC system (and allowing multi-threading or multi-
tasking in environments that support it) is a must. In the Network Computing
Architectures book, embedded microprocessors are specifically mentioned (page
18 if memory serves) ... are you suggesting that multi-threading be added
to these systems?

> Authentication and privacy features are part of NCS 2.0.

Maybe I am misunderstanding here, but it sounds like you are saying that NCS 2.0
will provide methods for authentication and for privacy that are 'hardcoded' 
into the system. If (for some reason) a customer has their own method that they
wish to use (i.e. their own encryption scheme) they will not be able to use it
and that instead they must use the method provided by NCS 2.0 ... am I jumping
to conclusions?

BTW, in some hallway discussions that we have had around here, the concept of
uniform transport behavior (sp?) has come up and it leaves me a bit puzzled. 
From my (perhaps somewhat limited) understanding of the current thinking in the 
networking community, there appear to be two camps, connection-oriented and
connection-less (thus the CO/CL split in the OSI) and what uniform transport
behavior in effect does is to come down clearly in the CO camp. (i.e. whether
the transport is CO or CL is unimportant (except in the case of broadcast) as
NCS establishes a CO protocol in either case). Is this the intent? The Netwise
approach is to have uniform CO transport behavior and uniform CL transport 
behavior and to therefore recognize this fundamental split ... I am curious
as to your thinking on this.

------------------------------------------------------------------------------
The verbiage above does not neccesarily reflect the views of my employer or
client (Netwise).

jake edge - L & E Technologies, Inc. 2888 Bluff St. Suite 142 Boulder, CO 80302 
    Ma Bell: (303) 440-1142                     UUCP: ...!onecom!wldrdg!jake