W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [XHR2] timeout

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 21 Dec 2011 16:47:52 +0100
To: "Jarred Nicholls" <jarred@webkit.org>, "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.v6ujh2v764w2qv@annevk-macbookpro.local>
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls <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


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


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


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Wednesday, 21 December 2011 15:48:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT