- From: Bill Janssen <janssen@parc.xerox.com>
- Date: Tue, 8 Aug 1995 20:19:36 PDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, Rich Salz <rsalz@osf.org>
Non-blocking RPC via the use of threads is not quite what we were talking about, I think -- doesn't every RPC system provide non-blocking RPC, if you specify the use of threads? But I could be wrong. The notion from the X Window System protocol that ILU preserves is that of streams of messages that can be sent, in blocks if necessary, without requiring replies. The other side of the connection can respond to these messages with other messages of its own. A problem with DCE RPC is the complexity of the messages and marshalling. While these complexities may in fact be useful for improving performance, I'm still skeptical if they do so sufficiently to pay for the added costs of implementation and testing. The size of the spec makes it more difficult to produce implementations, which would be, I think, a debit for use with the Web. It has certainly kept us from simply adding the DCE RPC wire protocol to the ILU suite. On the other hand, the semantics of DCE RPC are nicely defined, in sharp contrast to ONC RPC. Another problem with using DCE RPC, if my following of comp.soft-sys.dce has been correct, is that while the core of the RPC system is freely available, other parts, like the threads package necessary to implement your version of non-blocking RPC, aren't, so people are having a hard time getting the free DCE RPC code running. Similarly, the parts necessary for the secure part of your "...secure RPC...'' are not freely available. Perhaps this has changed lately, and I missed it? Bill
Received on Tuesday, 8 August 1995 20:20:50 UTC