Re: [FileAPI] Result of calling MultipleReads on FileReader

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 UTC