W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [FileAPI] Result of calling MultipleReads on FileReader

From: Eric Uhrhane <ericu@google.com>
Date: Thu, 31 Mar 2011 15:12:07 -0700
Message-ID: <BANLkTindVZch37STw1=z_uPKjP6v=DeWLQ@mail.gmail.com>
To: Adrian Bateman <adrianba@microsoft.com>
Cc: "arun@mozilla.com" <arun@mozilla.com>, "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 Thu, Mar 31, 2011 at 2:55 PM, Adrian Bateman <adrianba@microsoft.com> wrote:
> 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.

I think it's cleaner and simpler just to throw.  FileReader and XHR
are already different enough that a bit more, as long as it's a
usability improvement, isn't a big deal.  The efficiency improvement
is just a bonus.

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

Agreed on the need for this to be very explicit.  But I think we
should skip all the extra queued events by just making it illegal.

> Thanks,
>
> Adrian.
>
Received on Thursday, 31 March 2011 22:12:52 GMT

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