Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren <annevk@opera.com>wrote:

> On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls <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.


>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Thanks,
Jarred