Re: Slow HTTP Responses
Tony Sanders <sanders@BSDI.COM>
Message-id: <199401132358.RAA04736@austin.BSDI.COM>
To: www-talk@www0.cern.ch
Cc: Tim Berners-Lee <timbl@www0.cern.ch>
Subject: Re: Slow HTTP Responses
In-Reply-To: Your message of Thu, 13 Jan 1994 17:34:25 EST.
Organization: Berkeley Software Design, Inc.
Date: Thu, 13 Jan 1994 17:58:49 -0600
From: Tony Sanders <sanders@BSDI.COM>
Content-Length: 1815
> I vehemently disagree. An odometer should be a sign that some real
> work is being done. Put up an hourglass if all you want to show
> is "yes the client is still on a running computer but we're waiting."
> Would you have "option hash" in FTP fake the fact that transfer is
> taking place?
hash indicates *REAL* work being done, Mosaic already does this. Mosaic
also changes the cursor. Neither of these address the issue, The issue
being, what and how should the remote server be able to tell us about the
status of the request being processed. It's not clear to me at this point
that "Status:" is the right solution, HTTP is simply not designed as an
interactive protocol TTBOMK.
My current thinking on this general problem is that we need "protocol
callbacks", reply addresses for services provided by the client encoded
in the client's request to the server. For example, status messages could
be passed back via:
Services: Status/1.0 port=9994
Or, you might have the status monitor on another host:
Services: Status/1.0 port=9994,host=otherhost.dom
Or support an interactive audio/video service:
Services: AVsync/1.1 port=9995,chn=32,mode=HDTV.3
The status service should probably be UDP based, another reason
not to run it inside HTTP.
We could/should also define an interface standard for clients wanting to
run these services externally so, e.g., you could just get the AVsync
program and "hook it up" to your favorite client. Much thought still
needs to go into this, of course, but it seems a must for the long term.
Same goes for external content-type viewers. We need a high-end interface
language for talking about Hypertext objects between the client and
the viewer.
CGI has been a step in the right direction for the server end. Much
thanks to RobM for his effort there.
--sanders