- 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