Re: [XHR2] timeout

On Wed, Dec 21, 2011 at 3:54 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls <jarred@webkit.org>wrote:
>
>>  On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls <jarred@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
>
>