- From: Jarred Nicholls <jarred@webkit.org>
- Date: Wed, 21 Dec 2011 14:41:41 -0500
- To: olli@pettay.fi
- Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
- Message-ID: <CANufG2MXcqBt8dknLcYB6pkf+mi=5vwv5FuBuK8aG6sLK7E3Dw@mail.gmail.com>
On Wed, Dec 21, 2011 at 2:15 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
> On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
>
>> On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay <Olli.Pettay@helsinki.fi
>> <mailto:Olli.Pettay@helsinki.**fi <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>
>> <mailto: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>
>> <mailto: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>
>> >
>>
>>
>> <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? :)
>>
>> Ah, sync XHR in workers is a good case.
> So dataTimeout would fire if no data has been received in the
> dataTimeout period? And receiving some data would basically restart the
> timer?
Yeah that's the idea. Maybe it's valuable for the web platform, maybe it's
not.
>
>
>
>
>>
>> (timeout is being implemented in Gecko)
>>
>>
>> Awesome!
>>
>>
>>
>>
>> -Olli
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>>
>>
>> Thanks,
>> Jarred
>>
>>
>>
>>
>
Received on Wednesday, 21 December 2011 19:42:30 UTC