Path: utzoo!dciem!nrcaer!sce!cognos!craigs
From: craigs@cognos.UUCP (Craig Statchuk)
Newsgroups: comp.protocols.nfs
Subject: Re: "just RPCs"
Message-ID: <8435@cognos.UUCP>
Date: 4 Jun 90 13:42:54 GMT
References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <1990May24.205149.6065@Neon.Stanford.EDU> <3385@auspex.auspex.com> <1990May25.234950.1465@Neon.Stanford.EDU> <23682@bellcore.bellcore.com>
Reply-To: craigs@cognos.UUCP (Craig Statchuk)
Organization: Cognos Inc., Ottawa, Canada
Lines: 41

In article <23682@bellcore.bellcore.com> mo@messy.UUCP (Michael O'Dell) writes:
>
>No general RPC system I have heard of has the ability to add new
>functions on the fly - in fact, most are lauded for the ability
>to strongly-type interfaces and generate stubs for statically-
>linked code. 
>

When researching various RPC implementations, I also found that static
function definitions were most common.  Of course, the reason can
be traced to generation of "stubs" at compile time.  The advantage
of this technique is that  RPC protocols can be tested by linking
the remote application to the client application.  This allows RPC
routines to be run in the same context as the caller.  Note
that this technique cannot be used in asynchrous applications, where
the client and supplier are execting simultaneously.

The question I have is this: Is linking a client application "stub" to
the supplier (for testing) really very useful?  On a workstation,
where multiple tasks are simple to create and debug, why bother
running the client and the supplier as one task.  As separate tasks,
you get two debugger sessions, which can actually make debugging easier.

The alternative approach is to forget about generating call "stubs" at all
and implement RPC's with table definitions. The tables define
local routine addresses and parameter datatypes which are used
at run-time to actually invoke an RPC.  The advantage of this technique
is the easy re-definition (or creation) of functions and parameters 
"on the fly".  The downside, is that this method does not allow 
static linking of client to supplier.

Personally, I favour the latter implementation.

/CS


-- 
Craig Statchuk           USENET   : uunet!mitel!sce!cognos!craigs
Cognos Incorporated      INTERNET : craigs%cognos.uucp@uunet.uu.net
3755 Riverside Dr.       MaBellNET: (613) 738-1440
Ottawa, Ontario K1G 3Z4  FaxNET   : (613) 738-0002