HTTP problem or Mosaic problem?

Alan (wex@media.mit.edu)
Wed, 15 Jun 94 09:40:20 -0400


An alternative (and perhaps better) way to achieve the asynchrony that David
Berger needs for his MPEG layer would be to make HTTP a state-ful rather
than state-less protocol.

This would have a number of advantages:
- server could send parts of docs as needed/requested and know that
parts have been sent to what servers. This could *vastly* minimize
net traffic, as Mosaic could respond to a "back" request by asking
for just the first page of a doc. Since I often hit "back" several
times in a row, this would save having to get the whole bloody doc
when all I want to do is skip back a few steps.

(I'm sure we can all think of our own examples where getting a whole
document is really not what we want.)

- info providers could put large documents into the Web without
having to do a lot of work to break them up into tiny files.

- clients could tell servers more about themselves. For example, my
client may take data in any of 100 formats. It would be very nice
if I didn't have to send that whole list to the server every time I
retrieve a doc from it.

- semantic navigation would be much easier. If the server knows
that I'm following a trail of, say, documents on biology, it can
present me with a portion of the information it has, with that
portion I see being tailored to my current needs.

What's the advantage of a state-less protocol? It makes server writing
easier. But that throws the burden off onto clients, onto the net, and onto
information providers. You don't solve problems by shifting them around.

--Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard
Media Lab - Advanced Human Interface Group wex@media.mit.edu
Voice: 617-258-9168 Page: 617-945-1842 na53607@anon.penet.fi
It's not an information superhighway, it's an information kudzu.