WD-http-ng-goals-19980327 comments

Here's some more comments, on your earlier "Short & Long term goals"
document, 
http://www.w3.org/TR/1998/WD-http-ng-goals-19980327

In the "Introduction" section:
You write "..we would like the generic distributed object system
[HTTP-NG] to be simple, yet rich enough to meet the semantic and
performance requirements of CORBA, DCOM and Java RMI".
Hopefully, the intent is not simply to "meet" the models of these
others, 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.)

In "Gotta-Have-It" section:
Point 8, on caching, mentions "semantically transparent", and rules
to be followed to 'relax' this property. It isn't defined, and
it's not at all clear to me what is meant here by 'semantically
transparent'. May I suggest that this be made more explicit?
I'm guessing that this has something to do with letting the
client and/or server have more visible awareness of when their
information is being cached, and expressing their own context
on when it is safe/unsafe to use cached data as opposed to refreshing
it. Am I close?

Point 10 - well stated! Sort of motherhood-and-apple-pie, but
it really 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.

In "More is Better" Section:

Point 5 (Evolvability) and Point 10 (Transport Flexibility)
I believe are closely related. It's good to see the "non-TCP"
issue addressed, however I think it is broader than the
examples you give (Transactional TCP). If HTTP is ultimately
a (the?) unifying future for all sorts of networked content, such as
real time signals, isochronous data, group based shared state,
and more, HTTP will have to be able to sit comfortably over
much more than TCP & its kissing-cousins. And, the way to make
HTTP-NG evolveable (in the sense of pt. 5) to these many
kinds of applications is to be welcoming and supportive
of UDP-based, multicast-based, and more substrates. Ultimately,
what we need is a protocol composition kit that lets stacks
be negotiated and built at runtime by distributed applications.
And, this negotiation activity can't happen strictly from TCP-
and up. The barrier we currently have between IETF engineered-protocols
below the TCP/UDP surface, and application protocol experimentation
above it, has to be dissolved, so that protocol flavours can
be composed as needed throughout that space. (I.e. I am suggesting
that the barrier is artificial, retards growth, and that http-ng
may pose a unique forum in which to remove the barrier in
a way that is accessible to a bulk of applications which can
benefit from this.)

Note: 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,
to the exclusion of traffic that is best carried, and is already
carried, over non-TCP substrate.

Going on to read the "Binary Wire Protocol" and "Classic
Web Interfaces in HTTP-NG" next...

Best,
Ron
--------

Ron Resnick
DiaLogos Incorporated
http://www.dialogosweb.com

Received on Monday, 13 July 1998 10:33:40 UTC