mo@messy.bellcore.com (Michael O'Dell) (05/29/90)
Yes indeed, they are "just RPCs", at one level, but they are EXTENSIBLE! 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. The important point is that now the decision about the level of complexity of service interface need by a client from a server is now a decision which can be made by that CLIENT with precious little interference by the server. Different clients are free to make that decision in different ways! Further, pursuing the goal of "action at a distance," instead of "remote-izing local operations" is, in my view, mandatory for the future, and I, for one, am convinced that the traditional, non-dynamic RPC model isn't adequate for either experimentation or operational realities. We all learned somewhere along the way the "the later the binding the better, as long as you can afford it." I argue that what NeFS proposes takes this to new limits (extremes?) and the prospects are fascinating. -Mike
craigs@cognos.UUCP (Craig Statchuk) (06/04/90)
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