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

Jim said:
]
] So I intend to spend some time looking around at what is out there that
] may fulfill the requirements. (ILU from Xerox, and others that
] may be suggested to me).  Butler Lampson also pointed out to me that the
] exercise of looking around at existing systems will likely pay off in good
] ideas worth stealing, even if the RPC system itself isn't appropriate 
to this
] application. (If you can't steal good code, at least steal good 
ideas; a good
] motto, me thinks).
] 					- Jim Gettys
]
					  W3C
I agree.  There are at least these four  alternatives available to us:
1. Adopt an existing protocol and its implementation
2. Adopt an existing protocol and adapt some existing implementation
3. Adopt an existing protocol and do a new implementation
4. Do a new protocol and a new implementation
(And lots of others in between).

I believe that they are listed in order of desirability.

I don't think that the current DCE RPC _implementation_ has all the 
properties that we want of an implementation, that you listed. That 
means that if one picked it as the protocol, option #1 is not 
available. #2 might not be such a good idea either, but it might be OK 
-- there's at least a freely available source code base to start from. 
But #3 still seems preferable to #4, which seems to a direction we 
could easily head in.  In addition to avoiding the hard job of 
inventing a new protocol, it means that one can interoperate with 
existing clients and servers that use the existing implementation, even 
if that implementation is crummy.  (On the other hand, protocol design 
is fun, so I'll be glad to help if that seems like the best alternative 
when all has been investigated.)

Of course, if there is some other existing  protocol such that the both 
the protocol and an implementation have all the needed properties, then 
that's what we should do.

And the idea of using something like ILU as the existing implementation 
to adapt seems like it has merit too -- from Bill's description, the 
way it exposes the protocol features to the app works better in a low 
speed environment than the standard RPC programming model, which has 
trouble with asynchrony and incrementality (although with the benefit 
that the model is simpler to program, IMO).

I guess what I'm doing is adding to Butler's maxim that in addition to 
stealing good ideas, one can steal good protocol designs, too.

Paul

Received on Thursday, 10 August 1995 20:21:16 UTC