HTTP problem or Mosaic problem?

"Alan (Miburi-san) Wexelblat" <wex@media.mit.edu>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 15 Jun 1994 15:43:35 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406151340.AA12830@media.mit.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: wex@media.mit.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Alan (Miburi-san) Wexelblat" <wex@media.mit.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: HTTP problem or Mosaic problem?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
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.