On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren <ann...@opera.com
<mailto:ann...@opera.com>> wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
<jar...@webkit.org <mailto:jar...@webkit.org>> wrote:
1. The spec says the timeout should fire after the specified
number of
milliseconds has elapsed since the start of the request. I
presume this means literally that, with no bearing on whether or
not data is coming over the wire?
Right.
2. Given we have progress events, we can determine that data is
coming
over the wire and react accordingly (though in an ugly fashion,
semantically). E.g., the author can disable the timeout or
increase the timeout. Is that use case possible? In other
words, should setting the timeout value during an active request
reset the timer? Or should the
timer always be basing its elapsed time on the start time of the
request + the specified timeout value (an absolute point in the
future)? I
understand the language in the spec is saying the latter, but
perhaps could use emphasis that the timeout value can be changed
mid-request.
http://dvcs.w3.org/hg/xhr/rev/__2ffc908d998f
<http://dvcs.w3.org/hg/xhr/rev/2ffc908d998f>
Brilliant, no doubts about it now ;)
Furthermore, if the timeout value is set to a value > 0 but less
than the original value, and the elapsed time is past the
(start_time + timeout), do we fire the timeout or do we
effectively disable it?
The specification says "has passed" which seems reasonably clear to
me. I.e. you fire it.
Cool, agreed.
3. Since network stacks typically operate w/ timeouts based on data
coming over the wire, what about a different timeout attribute
that fires a timeout event when data has stalled, e.g.,
dataTimeout? I think this type of timeout would be more
desirable by authors to have control over for
async requests, since today it's kludgey to try and simulate
that with
timers/progress events + abort(). Whereas with the overall request
timeout, library authors already simulate that easily with
timers + abort() in the async context. For sync requests in
worker contexts, I can see a dataTimeout as being heavily
desired over a simple request timeout.
So if you receive no octet for dataTimeout milliseconds you get the
timeout event and the request terminates? Sounds reasonable.
Correct. Same timeout exception/event shared with the request timeout
attribute, and similar setter/getter steps; just having that separate
criteria for triggering it.
Is there really need for dataTimeout? You could easily use progress
events and .timeout to achieve similar functionality.
This was the reason why I originally asked that .timeout can be set also
when XHR is active.
xhr.onprogress = function() {
this.timeout += 250;
}
(timeout is being implemented in Gecko)
-Olli
--
Anne van Kesteren
http://annevankesteren.nl/
Thanks,
Jarred
