On Wed, Dec 21, 2011 at 2:20 PM, Glenn Maynard <[email protected]> wrote:
> On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay <[email protected]>wrote: > >> xhr.onprogress = function() { >> this.timeout += 250; >> } >> > > 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. It would also work fine for synchronous > requests. > > (I don't know what the use cases are for this, though.) > > On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls <[email protected]>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. You sound really self-conflicted based on how you started your message vs. how you ended it. > > > -- > Glenn Maynard > >
