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