- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Thu, 31 Mar 2011 21:55:08 +0000
- To: "arun@mozilla.com" <arun@mozilla.com>, Eric Uhrhane <ericu@google.com>
- CC: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>, Arun Ranganathan <aranganathan@mozilla.com>
On Thursday, March 31, 2011 10:19 AM, Arun Ranganathan wrote: > On 3/30/11 2:01 PM, Eric Uhrhane wrote: > > On Mon, Mar 28, 2011 at 5:37 PM, Adrian Bateman<adrianba@microsoft.com> > wrote: > >> Is there a reason for the current spec text? > > I don't know the original rationale, but in the absence of any strong > > technical constraint, I'd much prefer that subsequent read calls just > > throw an exception immediately. They seem likely to be indicative of > > bad code anyway, and it's so much easier to debug when you find out > > right away. > > > > The original rationale was to do what XHR does w.r.t. open()! > Essentially, the goal was: > > 1. To abort previous reads in favor of the last one, like how XHR does. > 2. The last read goes through. > > So: Adrian/Eric -- do you object to keeping this like XHR in terms of > aborting previous reads? What I should *definitely* do is make spec. > text more robust to reflect this; in general I want to make asynchronous > parts of this spec. more like HTML5 here. As long as the spec is clear I don't mind whether a subsequent read throws or includes an implicit abort() call. That's not the way I read the current spec text. We need to know things like whether we should queue any events for the abort or just silently move on to the new read, etc. It would be good if we can be explicit about when you're allowed to call readAsXXXX (this way it sounds like always) and if anything is different between the LOADING and DONE states. Thanks, Adrian.
Received on Thursday, 31 March 2011 21:55:37 UTC