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*
