Re: [FileAPI] Result of calling MultipleReads on FileReader

On 4/15/11 2:57 PM, Adrian Bateman wrote:
> On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote:
>> FileReader is extremely similar to XMLHttpRequest. The main difference
>> is in how you initiate the request (.open/.send vs. .readAsX). This
>> similarity is even getting stronger now that XHR gets .result.
>>
>> So I think there are good reasons to sticking to XMLHttpRequest here too.
>>
>> Note that no "error" events are fired by XMLHttpRequest. Just an
>> "abort" event. So "error" is still reserved for actual reading errors
>> whereas "abort" will fire for script-initiated aborts.
>>
>> I agree that calling .readAsX multiple times could be an indication of
>> developer bugs and as such could throw an exception. However I think
>> given the precedence set by XMLHttpRequest it could just as well mean
>> that a new resource is now the one that the author is interested in
>> reading.
> 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.

Eric: can you point out where you think FileReader explicitly deviates 
in style from XHR2?

-- A*

Received on Friday, 15 April 2011 19:16:50 UTC