Re: [XHR2] timeout

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

> On Wed, Dec 21, 2011 at 2:25 PM, Jarred Nicholls <jarred@webkit.org>wrote:
>
>>  You sound really self-conflicted based on how you started your message
>> vs. how you ended it.
>>
>
> Please be less vague.
>

My apologies.  See below.


> 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.
>

I agree.


> 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?

This then begs the question: why do we then have the response timeout?
 It's even easier and just as clean to write setTimeout(function() {
xhr.abort(); }, 2000);  Is it for synchronous requests in worker contexts?
 Is it because native timers are more reliable than JS setTimeout and the
UAs can make better decisions, a la requestAnimationFrame w/ repaints &
background pages, etc. etc.?  What use cases are there?

The point is, whatever reasons everyone agreed to have "timeout", the same
reasons apply to "dataTimeout".  Otherwise they both might as well be
dropped.


>
> --
> Glenn Maynard
>
>