Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!yale!mintaka!bloom-beacon!pae
From: pae@athena.mit.edu (Philip Earnhardt)
Newsgroups: comp.protocols.misc
Subject: Re: RPC Technologies
Message-ID: <1990Jul5.042028.16788@athena.mit.edu>
Date: 5 Jul 90 04:20:28 GMT
References: <4b423481.20b6d@apollo.HP.COM> <1990Jul5.040529.16093@athena.mit.edu> <1990Jul5.041344.16511@athena.mit.edu>
Sender: onecom!wldrdg!jake
Organization: L & E Technologies, Inc.
Lines: 69

In <4b2772cd.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin)
says:

> To cast the argument in the most extreme terms (always a good way to
> have a rational conversation :-), many people probably think the "asm"
> feature of C compilers is a good idea.  That doesn't mean it should be
> included in ANSI C.  I have no doubt that people have found ways to use
> Netwise's customization feature to do things that they've found useful.
> This doesn't mean it's a good idea.  It's simply too unconstrained.

It appears to me that what you are saying is that either NCS allows all 
possible mechanisms for client-server interaction or that if NCS doesn't
include a particular mechanism then a distributed systems designer shouldn't
need it and (more distressingly) shouldn't be able to use it.  From my
perspective, this is simply too constrained.  We constantly get calls from 
customers who have come up with perfectly valid ways to construct a client
server interaction that are not directly handled by the mechanisms that we
provide (and I suspect are not handled directly by the mechanisms available
with NCS).  Whereas you might claim that they are using the RPC mechanism in 
a way that 'breaks' the RPC paradigm, I would show them how to customize
their RPC spec to work in the way that they need it to.  It seems to me that
C language programmers (even ANSI C programmers :-) will be unwilling to 
allow any organization to completely limit their flexibility based on 
arbitrary 'standards' of client-server computing.  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 ...

> Further, I suspect it's frequently used to get around deficiencies in
> the base system.  

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.  

It seems to me that any 'base system' will have its own set of deficiencies 
based on the biases of the designers of the system and that the only real way to
get around these deficiencies is to allow for some kind of customization by
the end user.  It is clear that programmers are going to customize their 
application and that the best solution is to provide a well thought out 
mechanism that can be used to customize their code in a well defined way.  Some
questions:
   - 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?

[ RPC protocol description deleted ]

> As I understand it, the Netwise customization feature allows both the
> "RPC protocol" and the protocol specified by a particular interface
> definition to be manipulated in fairly arbitrary ways.  First, I think
> that being able to manipulate the RPC protocol itself is a bad idea (for
> the reasons I stated above).  

Once again, unless the 'base system' provides for all possible models of
client-server computation, you are going to have some unhappy customers. These
customers may have to go through wild gyrations to get around arbitrary 
restrictions placed on them by the base system, but in the end they will 
customize their application to work with the model of their choosing.

jake edge
L & E Technologies, Inc. (303) 440-1142
...!onecom!wldrdg!jake

Disclaimer: For all of the usual reasons, what I say does not neccesarily 
   reflect the views of my employer ... in addition, my views do not
   neccesarily reflect those of my client (Netwise).