Re: WD-http-ng-goals-19980327 comments

> Hopefully, the intent is not simply to "meet" the models of these
> others [CORBA, DCOM, Java RMI], but to actually go beyond them as
> necessary/possible/appropriate. (This is certainly obvious
> in the rest of your documentation, but isn't so boldly stated
> up front.)

Well, the point of the structure and strength you see is to try to say what we
mean about "necessary/possible/appropriate".  While some of us would *like* to
go beyond the those existing systems as far as possible, this is supposed to
mainly not be a research project, so we really shouldn't make bold statements
about doing better as goals.  Of course, in the evaluation criteria, we don't
deny that better is better ;-)


Wrt defining "semantically transparent": This document doesn't attempt to give
an exact semantic definition of HTTP-NG --- that's an output, not something
you
start with as a goal.  Lacking exact semantics, we can't very well define
"semantically transparent".  However, this term is lifted verbatim from the
HTTP/1.1 spec, and the intent is to suggest the appropriate NG-ification of
that definition --- whatever we end up realizing "appropriate" is.


> Point 10 - well stated! ... gets to the heart of the difference between what
> it takes to make the web a d-o infrastructure, as opposed to building
> a first principles d-o architecture like CORBA.

Actually, I don't think CORBA is all that different from what is outlined in
"Gotta-Have-It" point 10.  Certainly CORBA does not suppose central
administration of servers and clients --- however I think CORBA does not
support incremental deployment of evoluationary changes as well as the
existing
web.  The biggest difference I see is that CORBA doesn't talk about protocol
flexibility --- except to the (not inconsiderable) degree that different
network interfaces can be considered different "protocols".  And I haven't
studied CORBA's security story closely enough to comment wrt this point.


> In "More is Better" Section:
>
> Point 5 (Evolvability) and Point 10 (Transport Flexibility)
> I believe are closely related. ...
>
> After writing this last para, I read the SMUX spec
> (WD-mux-19980710). In general, it reaffirms the impression I have,
> that the goals of HTTP-NG seem to be overly narrowly focused on TCP, ...

While SMUX is specifically directed at solving some problems with the way HTTP
uses TCP, the goal and thinking about transport flexibility really is broader
than "TCP & its kissing-cousins".  If you read the architecture document,
you'll see the kind of transport protocol stacking you describe, and it's not
even limited to the Internet, let alone TCP.  This feature has been in ILU for
years, and ILU used to support UDP and a non-Internet sequenced-packet
protocol
(XNS SPP) as well as TCP (these have rotted due mainly to lack of user
interest).  Whether these stacks need to be negotiated at runtime is a
subsidiary matter, on which I have not made up my mind.  The evaluation
criterion is open enough that any relevant aspects of transport flexibility
can
be encompassed.

Mike

Received on Monday, 13 July 1998 19:04:40 UTC