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.Pettay@helsinki.fi
> <mailto: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>>
>
>
>         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?


>
>
>     (timeout is being implemented in Gecko)
>
>
> Awesome!
>
>
>
>
>     -Olli
>
>
>
>
>
>
>
>
>             --
>             Anne van Kesteren
>         http://annevankesteren.nl/
>
>
>         Thanks,
>         Jarred
>
>
>

Received on Wednesday, 21 December 2011 19:16:34 UTC