Re: Search feedback (was: Re: Slow HTTP Responses)
robm@ncsa.uiuc.edu (Rob McCool)
Message-id: <9401151002.AA06465@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Sat, 15 Jan 1994 04:02:09 -0600
In-Reply-To: Larry Masinter <masinter@parc.xerox.com>
"Re: Search feedback (was: Re: Slow HTTP Responses)" (Jan 14, 6:20pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Larry Masinter <masinter@parc.xerox.com>, www-talk@www0.cern.ch
Subject: Re: Search feedback (was: Re: Slow HTTP Responses)
Content-Length: 1100
/*
* Re: Search feedback (was: Re: Slow HTTP Responses) by Larry Masinter (masinter@parc.xerox.com)
* written on Jan 14, 6:20pm.
*
* There are two independent issues:
*
* 1) what channel is used for sending status information back.
* Async UDP
* In-band escape sequences
* ...
The beauty of Tony's suggestion is that it defines no channel... it only
defines that the channel used is not the current HTTP connection.
* (maybe this is something that you specify in your 'GET' request
* if you're willing to accept them, and something that comes
* back in the header if there's a place to recieve them)
Exactly.
* 2) What is the nature of the progress report:
* percentage complete
* amount of time remaining
* X out of Y as Strata Rose indicated
Again, Tony's proposal allows any of these (and the ones people come up with
years from now) to be integrated easily.
* I think we can manage to support all combinations of these,
* optionally, in the protocol, and then see what actually gets
* implemented and supported.
*/
Exactly.
--Rob