W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

RE: [FileAPI] Result of calling MultipleReads on FileReader

From: Adrian Bateman <adrianba@microsoft.com>
Date: Fri, 15 Apr 2011 19:53:26 +0000
To: "arun@mozilla.com" <arun@mozilla.com>
CC: Jonas Sicking <jonas@sicking.cc>, Eric Uhrhane <ericu@google.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB3D33A49D@TK5EX14MBXC136.redmond.corp.microsoft.com>
On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote:
> On 4/15/11 2:57 PM, Adrian Bateman wrote:
> > With this in mind, I don't personally have a strong feeling either way
> > between having to call abort() explicitly or having readAsXXX implicitly
> > call abort(). I've discussed it with others at Microsoft this week and the
> > consensus here is that the defensive exception is better and that developers
> > should have to call abort() if they want to abandon the current operation.
> > I think we could live with either but right now we're planning for throwing
> > the exception. We'd like to make a decision one way or the other pretty
> > soon.
> 
> Adrian: I'm keen to have behavior similar to XHR, and not raise an
> exception in this case.  From your note above, I'm gathering you can
> live with an XHR-style abort which FileReader can fire on readAsXXX
> calls that have been superseded.

Yes, we could live with it but the semantics are more complex. Is this the same
as calling abort() then readAsXXX()? When does the abort event get queued? What
will be the state of the reader at this point? Will loadend get fired? It needs
careful speccing to make sure that the details are handled the same in different
implementations.

Adrian.
Received on Friday, 15 April 2011 19:53:54 GMT

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