Re: [XHR2] timeout

On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
> On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren <annevk@opera.com
> <mailto:annevk@opera.com>> wrote:
>
>     On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
>     <jarred@webkit.org <mailto:jarred@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

Received on Wednesday, 21 December 2011 18:35:48 UTC