Re: [XHR2] timeout

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.

-- 
Glenn Maynard