Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> 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>
>>
>>    <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;
> }
>

Then why have timeout at all?  Your workaround for a native dataTimeout is
analogous to using a setTimeout + xhr.abort() to simulate the request
timeout.

I can tell you why I believe we should have dataTimeout in addition to
timeout:

   1. Clean code, which is better for authors and the web platform.  To
   achieve the same results as a native dataTimeout, your snippet would need
   to be amended to maintain the time of the start of the request and
   calculate the difference between that and the time the progress event fired
   + your timeout value:

   xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout;

   A dataTimeout is a buffered timer that's reset on each octet of data
   that's received; a sliding window of elapsed time before timing out.  Every
   time the above snippet is calculated, it becomes more and more erroneous;
   the margin of error increases because of time delays of JS events being
   dispatched, etc.
   2. Synchronous requests in worker contexts have no way to simulate this
   behavior, for request timeouts nor for data timeouts.  Most of the network
   stacks in browsers have a default data timeout (e.g. 10 seconds) but
   allowing the author to override that timeout has value I'd think.  With
   that said... synchronous requests? What are those? :)



>
>
> (timeout is being implemented in Gecko)


Awesome!


>
>
>
> -Olli
>
>
>
>
>
>>
>>
>>
>>    --
>>    Anne van Kesteren
>>    http://annevankesteren.nl/
>>
>>
>> Thanks,
>> Jarred
>>
>
>