Slippery Slope (was Status: -> Progress:)

dglazer@verity.com
Wed, 11 May 94 10:01:09 PDT


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