Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!mishkin
From: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Newsgroups: comp.protocols.misc
Subject: Re: RPC Technologies
Message-ID: <4b69c9e1.20b6d@apollo.HP.COM>
Date: 5 Jul 90 18:49:00 GMT
References: <4b423481.20b6d@apollo.HP.COM> <1990Jul5.040529.16093@athena.mit.edu> <1990Jul5.041344.16511@athena.mit.edu>, <1990Jul5.042028.16788@athena.mit.edu>
Sender: root@apollo.HP.COM
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 47

> Of course, there is 
> danger inherent in the customization features of the RPC Tool, but these 
> dangers are offset by the benefits gained ... there are also dangers in 
> using pointers in C and their use is largely unconstrained, this doesn't
> mean it's a good idea to remove them from the language ...

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

> Just out of curiousity, have you ever used the Netwise RPC Tool?  I have not
> used NCS so anything that I have said here is mostly from hearsay.  

I've read the documentation and seen bits of code (samples, examples, etc.)
written to use it.

>    - Does NCS 1.x provide mechanisms for asynchronous RPC calls? callback 
>      routines? user-specified encryption algorithms (i.e. for someone
>      who doesn't trust that the NSA hasn't broken the DES)? auditing of
>      arbitrary user-specified parameters/statistics? 
>    - Does NCS 2.0 add any of these features?

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

NCS 2.0 supports callbacks to known procedures (i.e., not callbacks through
passed procedure pointers).  Our intention to to support callbacks in
general as part of the base system.

Authentication and privacy features are part of NCS 2.0.

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