- From: Arun Ranganathan <arun@mozilla.com>
- Date: Thu, 31 Mar 2011 13:18:30 -0400
- To: Eric Uhrhane <ericu@google.com>, Adrian Bateman <adrianba@microsoft.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>
Eric, Adrian, 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: >> As we continue to experiment with the File API, I'm trying to understand the >> rationale for the Multiple Reads section: >> http://dev.w3.org/2006/webapi/FileAPI/#MultipleReads >> >> The spec says: >> >> If multiple read methods are called on the same FileReader object, user >> agents MUST only process the last call to a read method, which is the >> call that occurs last in a script block that has the "already started" >> flag set [HTML5]. >> >> I'm trying to understand the rationale for respecting the LAST call - is it >> common for people to call read lots of times and want the last one to be >> respected. Since the read happens asynchronously, we'd rather kick off the >> read operation as soon as the first read is called and give an error to >> subsequent read calls. I'm not sure what the use case is for wanting the last >> one (you can always call abort() and start again). >> >> 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. -- A*
Received on Thursday, 31 March 2011 17:19:10 UTC