On Wed, Dec 21, 2011 at 2:15 PM, Olli Pettay <[email protected]>wrote:
> On 12/21/2011 08:59 PM, Jarred Nicholls wrote: > >> On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay <[email protected] >> <mailto:Olli.Pettay@helsinki.**fi <[email protected]>>> wrote: >> >> On 12/21/2011 05:59 PM, Jarred Nicholls wrote: >> >> On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> 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 >> >> >> >> >
