- From: Scott Lawrence <lawrence@agranat.com>
- Date: Tue, 28 Jul 1998 21:21:08 +0000
- To: NG Comments <www-http-ng-comments@w3.org>
To quote from the 'Short and Long Term Goals' [1] of the W3C HTTP-NG
Activity [2]:
The goal of the HTTP-NG project is to test the hypothesis that
the current HTTP/1.X approach to web protocol design can be
replaced with one in which the Web is expressed as a particular
set of interfaces on top of a generic distributed object system
designed with Internet constraints in mind. We expect that a
layered approach would bring many benefits to the Web,
including easier evolution of the protocol standard, interface
technology that would facilitate Web automation, easier
application building, and so on.
First, I think that the more interesting question is whether or not
the current approach to web protocols _should_ (as opposed to 'can'
above) be "replaced with one in which the Web is ... a generic
distributed object system".
It _may_ be true that a generic distributed object system would
provide a better foundation for some kinds of distributed
applications. However, I think that it is usefull to examine
whether or not this is true for the Web as a whole and for future
versions of HTTP in particular.
I believe that the explosive growth of the Web can in large part be
traced to the loose coupling between servers and clients. The
structure (I hesitate to call it an 'architecture') of the Web to
this point has specifically _not_ been that of a distributed
application, but a set of applications communicating in a simple
way, passing content that each is free to interpret (or
misinterpret) according to its own capabilities. Servers in general
have only a vague notion of the capabilities of clients, and clients
only a very simple set of interactions with servers. While a
problem if viewed as building a distributed application, this has
contributed to making it easy to experiment with new capabilities.
This easy experimentation, even on a large scale, has caused
capabilities to undergo a 'selection of the most popular'. Server
operators are often faced with the decision of whether or not to use
a particular technology that may not be deployed widely enough to
meet thier needs, and have generally found good ways to deal with
the tradeoffs (links to pluggins or alternate versions of a page),
but as a particular technology becomes available that provides
attractive new capabilities, users tend to adopt them quickly and
servers can use them with increasing confidence (eg. inline images,
animated GIFs, RealAudio, frames, Javascript).
With the exception of the MUX layer, the rest of the architecture
examined by the HTTP-NG project represents more a radical departure
from HTTP than an evolution of it. It abandons not only loose
server/client coupling, but also the fact that HTTP is human
readable - a factor that has contributed to making HTTP interactions
easy to debug, and which follows in the footsteps of the most widely
deployed protocols above TCP in the Internet protocol family (SMTP,
NNTP).
Distributed object oriented frameworks may be a good way to build
some kinds of distributed systems, but I don't believe that anyone
can cite an example of any distributed system that has seen anything
like the rapid evolution and acceptance of the loosely coupled
components that make up the Web; let us not abandon them lightly.
If the existing distributed object frameworks have shortcomings as
enhancements to existing Web technologies, those should be addressed
either by evolving them or by replacing them (perhaps with something
like the framework HTTP-NG examined). I don't think, however that
this should be viewed as a replacement for the loosely coupled
approach of HTTP; it should instead be considered as a new protocol
complementry to HTTP and unencumbered by the necessity of any sort
of backward compatibility with it. The whole discussion of how one
might implement HTTP/1.x using HTTP-NG becomes moot, and whatever it
is called (OTIP - Object Transport Interaction Protocol) is free to
be designed to meet the needs of a different class of problems for
which HTTP is ill suited. HTTP/X need not be the only protocol in
the Web (it isn't even now); let us not try to build a single hammer
than can drive everything from carpet tacks to bridge pilings.
--
Scott Lawrence Consulting Engineer <lawrence@agranat.com>
Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/
Received on Tuesday, 28 July 1998 17:20:40 UTC