W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Draft Minutes of HTTP Working Group, 33rd IETF Meeting, Stockholm

From: Bill Janssen <janssen@parc.xerox.com>
Date: Tue, 8 Aug 1995 20:19:36 PDT
Message-Id: <8k_2Z88B0KGWI98t84@holmes.parc.xerox.com>
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

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?

Received on Tuesday, 8 August 1995 20:20:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC