Re: Slow HTTP Responses

Rich Wiggins <WIGGINS@msu.edu>
Message-id: <9401142209.AA24323@dxmint.cern.ch>
Date:         Fri, 14 Jan 94 17:00:19 EST
From: Rich Wiggins <WIGGINS@msu.edu>
Subject:      Re: Slow HTTP Responses
To: Tony Sanders <sanders@BSDI.COM>, www-talk@www0.cern.ch
In-reply-to: Your message of Thu, 13 Jan 1994 17:58:49 -0600
Content-Length: 1781

>> 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.

Regardless of the merits of the Status proposal, the spinning globe
does NOT equate to hash: sometimes the globe spins when nothing is
being transferred -- I've had it spin in WinMosaic while a dialog
box sits telling me the fetch failed.  Moreover, Option Hash gives
you a visual indication as to the amount of work that has been
accomplished -- it's a count of blocks transferred.  Users can't
count globe revolutions as a measure of work done.

I can picture lots of situations where it'd be very nice to have
a standard status mechanism.  Suppose the info you want is offline
and must be fetched with an unknown wait for posting online.  Suppose
the server is hunting around a huge database (or the Internet) for
your answer.  An odometer reflecting real work done (which is not
necessarily the same thing as amount of data transferred to the
user, by the way) could be extremely useful.

Whether the particular proposal for communicating back status info
is the best scheme or not, having the client fake a "warm fuzzy"
indicator does not address the need expressed.


/rich