Slippery Slope (was Status: -> Progress:)

• Mail folder: WWW Talk Apr 94-present
• Next message: Kevin Altis: "HTML and HTTP to RFC status is job 1"
• Previous message: Rick Troth: "Re: Status: -> Progress:"

Errors-To: listmaster@www0.cern.ch
Date: Wed, 11 May 1994 19:08:01 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405111701.AA00247@chili.verity.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: dglazer@verity.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: dglazer@verity.com
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Slippery Slope (was Status: -> Progress:)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

It seems to me that many of the proposed HTTP enhancements are walking a
slippery slope from today's connection-free model towards a connection-based
model.  Once you keep the connection between the server and the client active
for a long time (e.g. long enough for 'Progress' messages to be appropriate,
or long enough for dynamic updating of content to be useful), you might as
well provide full two-way communication back and forth between the client and
the server.

This two-way channel would allow higher interactivity.  Info providers could
design pages with a mix of the newly available push model (the server updates
the screen to indicate fast-breaking news, availability of new information, or
the arrival of a new response) and today's pull model (the user clicks on a
"What's New" button, the client updates the screen whenever the user is idle).

The main drawbacks that I see are that everything is more heavyweight.
  1) tying up network resources (To borrow someone's Web ftp analogy, we would
     be buying everyone an 18-wheeler, replacing all those pesky little
     motorcycles that are darting in and out of traffic.)
     
  2) complexity (Having state means dealing with state.  If the connection
     goes down, we need mechanisms to recover somewhat smoothly.  If a session
     lasts for a while, predicting and debugging correct behavior gets
     trickier.)

Having pushed further down (up?) the slippery slope, I find myself with
mixed feelings.  I'd love the functionality provided by connections, but I'm
concerned about killing the beautiful simplicity of "GET URL" returning an
HTML document.  As usual, some halfway and/or mixed solution is probably the
best choice.

What do people think?

  - dG

David Glazer - Verity, Inc. - Mountain View, CA