Re: [XHR2] timeout
Are any user agents other than IE8+ currently implementing or have implemented XHR2 timeout? https://bugs.webkit.org/show_bug.cgi?id=74802 I have a couple of things I wanted to question, which may or may not result in clarification in the spec. 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? 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. 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? 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. Thanks, Jarred
Re: [XHR2] timeout
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/
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.comwrote: 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/**2ffc908d998fhttp://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
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 ann...@opera.com
mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto: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
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
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.com
mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto: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/**__2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/__2ffc908d998f
http://dvcs.w3.org/hg/xhr/**rev/2ffc908d998fhttp://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
Re: [XHR2] timeout
On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@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
ann...@opera.com mailto:ann...@opera.com
mailto:ann...@opera.com mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto:jar...@webkit.org
mailto:jar...@webkit.org mailto: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
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.
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
xhr.onprogress = function() {
this.timeout += 250;
}
What if a UA suspends scripts in background pages (eg. to save battery),
but allows XHR requests to continue? This would time out as soon as that
happened.
This particular snippet seems to be trying to do work that the browser
should be taking care of. If there's really a use case for must receive
some data every N milliseconds, in addition to .timeout (the whole
request must complete in N milliseconds), then it seems better to add a
separate timeout property for that instead of encouraging people to
implement timeouts by hand. It would also work fine for synchronous
requests.
(I don't know what the use cases are for this, though.)
On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.org wrote:
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;
This, at least, doesn't seem interesting. I don't think it's worthwhile
to add new APIs just so people don't have to do simple math.
var now = new Date().getTime();
xhr.timeout = now - requestStart + timeoutLength;
This is simple and clean; there's no need to complicate the platform for
this.
--
Glenn Maynard
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 2:20 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
xhr.onprogress = function() {
this.timeout += 250;
}
What if a UA suspends scripts in background pages (eg. to save battery),
but allows XHR requests to continue? This would time out as soon as that
happened.
This particular snippet seems to be trying to do work that the browser
should be taking care of. If there's really a use case for must receive
some data every N milliseconds, in addition to .timeout (the whole
request must complete in N milliseconds), then it seems better to add a
separate timeout property for that instead of encouraging people to
implement timeouts by hand. It would also work fine for synchronous
requests.
(I don't know what the use cases are for this, though.)
On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.orgwrote:
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;
This, at least, doesn't seem interesting. I don't think it's worthwhile
to add new APIs just so people don't have to do simple math.
var now = new Date().getTime();
xhr.timeout = now - requestStart + timeoutLength;
This is simple and clean; there's no need to complicate the platform for
this.
You sound really self-conflicted based on how you started your message vs.
how you ended it.
--
Glenn Maynard
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 2:25 PM, Jarred Nicholls jar...@webkit.org wrote: You sound really self-conflicted based on how you started your message vs. how you ended it. Please be less vague. -- Glenn Maynard
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 2:15 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:Olli.Pettay@helsinki.**fi olli.pet...@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
ann...@opera.com mailto:ann...@opera.com
mailto:ann...@opera.com mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto:jar...@webkit.org
mailto:jar...@webkit.org mailto: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/**2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/2ffc908d998f
http://dvcs.w3.org/hg/xhr/**rev/__2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/__2ffc908d998f
http://dvcs.w3.org/hg/xhr/__**rev/2ffc908d998fhttp://dvcs.w3.org/hg/xhr/__rev/2ffc908d998f
http://dvcs.w3.org/hg/xhr/**rev/2ffc908d998fhttp://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
Re: [XHR2] timeout
(11/12/21 23:47), Anne van Kesteren wrote: 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. Does this need to be clarified? follow the same-origin request event rules has the premise as data becomes available and when the user interferes with the request and timeout seems a bit special here.
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls jar...@webkit.org wrote: On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.org wrote: 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; This, at least, doesn't seem interesting. I don't think it's worthwhile to add new APIs just so people don't have to do simple math. var now = new Date().getTime(); xhr.timeout = now - requestStart + timeoutLength; This is simple and clean; there's no need to complicate the platform for this. And now writing timers by hand is okay? First, this is a response to the specific point above about clean code, not an argument that using timers this way is necessarily a good idea. Computing a relative timeout delay just isn't complicated. Second, my note to Olli was about using onprogress, not setTimeout. His onprogress example might encounter problems if the UA suspends scripts but not transfers (in order to give predictable battery usage for backgrounded apps). Using setTimeout for completion timeouts might be okay, since the UA would probably also delay timers if it was suspending scripts. The point is, whatever reasons everyone agreed to have timeout, the same reasons apply to dataTimeout. Otherwise they both might as well be dropped. One possible reason--which came to mind writing the above--is that setTimeout delays can be arbitrarily longer than requested. If a UA suspends scripts for ten minutes (eg. the user switches tasks on his phone), and the timeout is setTimeout(f, 60*5), it could result in a 15-minute-long timeout, with the timeout never triggering while backgrounded (so the UA keeps trying unnecessarily). That doesn't automatically means that a data received timeout is needed, though; it still needs use cases. -- Glenn Maynard
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 3:54 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls jar...@webkit.orgwrote: On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.org wrote: 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; This, at least, doesn't seem interesting. I don't think it's worthwhile to add new APIs just so people don't have to do simple math. var now = new Date().getTime(); xhr.timeout = now - requestStart + timeoutLength; This is simple and clean; there's no need to complicate the platform for this. And now writing timers by hand is okay? First, this is a response to the specific point above about clean code, not an argument that using timers this way is necessarily a good idea. Computing a relative timeout delay just isn't complicated. Second, my note to Olli was about using onprogress, not setTimeout. His onprogress example might encounter problems if the UA suspends scripts but not transfers (in order to give predictable battery usage for backgrounded apps). Using setTimeout for completion timeouts might be okay, since the UA would probably also delay timers if it was suspending scripts. The point is, whatever reasons everyone agreed to have timeout, the same reasons apply to dataTimeout. Otherwise they both might as well be dropped. One possible reason--which came to mind writing the above--is that setTimeout delays can be arbitrarily longer than requested. If a UA suspends scripts for ten minutes (eg. the user switches tasks on his phone), and the timeout is setTimeout(f, 60*5), it could result in a 15-minute-long timeout, with the timeout never triggering while backgrounded (so the UA keeps trying unnecessarily). That doesn't automatically means that a data received timeout is needed, though; it still needs use cases. What are our use cases for the request timeout? We can start there and begin a new thread. Likely most of the same use cases apply, only in the context of data (or the lack thereof) being the criteria for firing the timeout as opposed to the overall request time. I would just like to stress that the same reasons (apart from sync requests, some Glenn that you mentioned above) setTimeout doesn't suffice to fully simulate the currently specced request timeout, are also applicable to why scripting progress events w/ the request timeout doesn't suffice to fully simulate the idea of a data timeout. -- Glenn Maynard
Re: [XHR2] timeout
On Tue, 15 Mar 2011 14:54:28 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: I think timeout is a bit too limiting. Especially the step 2. If the send() flag is true raise an INVALID_STATE_ERR exception and terminate these steps. Setting timeout no longer throws and invoking open() no longer resets it. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-xmlhttprequest-timeout Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] timeout
On 11/12/2009 05:24 PM, Anne van Kesteren wrote:
On Wed, 11 Nov 2009 00:03:07 +0100, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 10, 2009 at 10:17 AM, Anne van Kesteren ann...@opera.com
wrote:
Anyway, do you have opinions on the synchronous case? Do you agree we
should use TIMEOUT_ERR there? What do the people from Microsoft think?
That makes sense to me.
I've now defined the timeout feature:
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
Please review it! (Same for FormData and really all other parts of the
specification.)
I think timeout is a bit too limiting. Especially the step
2. If the send() flag is true raise an INVALID_STATE_ERR exception and
terminate these steps.
What if dns resolving (or something else) takes just a bit too long and
then the timeout fires while something is being downloaded.
Whoever is using the API may have already read part of the data and may
want to get rest of it.
So, could we allow increasing timeout value also after send().
Setting timeout to 0 to clear it should also be possible.
This way one could increase the timeout if needed.
var xhr = new XMLHttpRequest();
xhr.open(...);
xhr.timeout = 1; //10s
xhr.onprogress = function(evt) {
// Ok, some progress is happening, increase the timeout so
// that only very slowly loading XHR is cancelled.
if (xhr.timeout == 1) {
xhr.timeout *= 2;
}
}
xhr.send();
-Olli
Re: [XHR2] timeout
On Wed, 11 Nov 2009 00:03:07 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 10, 2009 at 10:17 AM, Anne van Kesteren ann...@opera.com wrote: Anyway, do you have opinions on the synchronous case? Do you agree we should use TIMEOUT_ERR there? What do the people from Microsoft think? That makes sense to me. I've now defined the timeout feature: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Please review it! (Same for FormData and really all other parts of the specification.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] timeout
On Tue, Nov 10, 2009 at 5:22 PM, Anne van Kesteren ann...@opera.com wrote: I was looking at defining the timeout feature. For consistency with abort error and network error it would make sense to introduce a TIMEOUT_ERR for synchronous requests, but Internet Explorer is probably not doing this (at least not per documentation). For consistency with abort error and network error it would make sense to dispatch a readystatechange event. Per comments from Sunava Internet Explorer does not do this. Similarly it would make sense to move the state of the object to 4 rather than 0. Again, per Sunava Internet Explorer does not do this. Personally I think we want to dispatch the readystatechange event, we want to switch the state of the object to 4, we want to dispatch a loadend event after the timeout event, we do not want to dispatch an abort event (this was suggested before), and we want to throw a TIMEOUT_ERR exception (code 23 or 24, depending on whether we want to reserve 23 for v2-datagrid) for the synchronous request case rather than dispatching events. I also think we want to dispatch the timeout event to the XMLHttpRequestUpload object (in the asynchronous case) for consistency. Thoughts? Are all of these comments for synchronous XHR only? I agree with most of your comments. Though I think we should fire an abort event since Progress Events spec says to fire one of abort/error/load, and abort seems to fit the bill the best. Or are you suggesting that Progress Events should say that one of abort/error/load/timeout is always fired? I agree that firing readystatechange seems like the most consistent thing to do. I agree that firing timeout (and IMHO abort) on the XHRUpload object unless upload has already finished. In general, I think essentially behaving as if a timeout event was fired, and then abort() is called is how we should behave. / Jonas
Re: [XHR2] timeout
On Tue, 10 Nov 2009 18:23:04 +0100, Jonas Sicking jo...@sicking.cc wrote: Are all of these comments for synchronous XHR only? Only the TIMEOUT_ERR exception was for the synchronous case. I think the synchronous case it would be most consistent to not dispatch any events. This is however not what Internet Explorer is currently doing as I understand things (have not been able to test yet). I agree with most of your comments. Though I think we should fire an abort event since Progress Events spec says to fire one of abort/error/load, and abort seems to fit the bill the best. Or are you suggesting that Progress Events should say that one of abort/error/load/timeout is always fired? It seems better to change Progress Events. We already agreed to make requirements on specifications less strict. I agree that firing readystatechange seems like the most consistent thing to do. I agree that firing timeout (and IMHO abort) on the XHRUpload object unless upload has already finished. In general, I think essentially behaving as if a timeout event was fired, and then abort() is called is how we should behave. abort() has some legacy attached to it that I rather not copy. I rather copy how the generic abort error network steps behave. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] timeout
On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren ann...@opera.com wrote: I agree that firing readystatechange seems like the most consistent thing to do. I agree that firing timeout (and IMHO abort) on the XHRUpload object unless upload has already finished. In general, I think essentially behaving as if a timeout event was fired, and then abort() is called is how we should behave. abort() has some legacy attached to it that I rather not copy. Such as? / Jonas
Re: [XHR2] timeout
On Tue, 10 Nov 2009 18:41:32 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren ann...@opera.com wrote: abort() has some legacy attached to it that I rather not copy. Such as? Actually, apart from switching the state to 0 in the end there is nothing. (This does not happen for user aborts though so I still rather not copy that.) Anyway, do you have opinions on the synchronous case? Do you agree we should use TIMEOUT_ERR there? What do the people from Microsoft think? -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] timeout
On Tue, Nov 10, 2009 at 10:17 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 10 Nov 2009 18:41:32 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren ann...@opera.com wrote: abort() has some legacy attached to it that I rather not copy. Such as? Actually, apart from switching the state to 0 in the end there is nothing. (This does not happen for user aborts though so I still rather not copy that.) Anyway, do you have opinions on the synchronous case? Do you agree we should use TIMEOUT_ERR there? What do the people from Microsoft think? That makes sense to me. / Jonas
