On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls <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
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.
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.
--
Anne van Kesteren
http://annevankesteren.nl/
