Re: [FileAPI] Result of calling MultipleReads on FileReader

Apologies for the slow response.  I wanted to go back and reread the
relevant specs before I said anything more.  Having done so, I found
that XHR and FileReader were more similar than I had remembered.
However, I believe I also found that the exception solution is just as
consistent with XHR as the abort.

On Fri, Apr 15, 2011 at 12:16 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> 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?

It's not so much a difference in style as it is a difference in functionality.

With XHR, you:

Create one via the constructor
[set handlers anywhere before returning]
Call open()
[optionally set headers, response type]
Call send()

With FileReader you:

Create one via the constructor
[set handlers anywhere before returning]
Call one of the read() methods

So depending on how you think of it, either:

1) read == open + send;
2) read == send, and FileReader has no equivalent to open
3) read == open, and FileReader has no send.

In XHR, if you open after send, the current request will abort with no
error--I believe that's the behavior Arun wants to emulate.  That
seems to be what you get if you use interpretation 1.  Two reads in a
row mean "I've changed my mind".  I have yet to hear a strong argument
that that's likely to happen [sorry Jonas]; it still seems to me that
it's far more likely to be programmer error.  However, it's clearly
within the spirit of XHR to go this way.

However, if in XHR you try to send when the state is not OPENED or
when the send() flag is set, it'll throw an exception.  Calling send()
sets the send() flag synchronously, so if you call send() twice in a
row, you'll get INVALID_STATE_ERR exception on the second call, and
the first request will not abort.  That's the behavior I'd like to
emulate--a fast failure on an obvious coding error--and it follows
obviously from interpretation 2.  Adding a check that readyState is
not LOADING would have much the same effect as the send() flag check.

Interpretation 3 doesn't seem to match quite as well, as nothing
happens if you stop after open(), and anyway we don't need a three-way
debate ;'>.

I think we have a free choice which way we go, since either 1 or 2
would maintain the [a?] spirit of the XHR interface.  So I favor the
one I think is generally more programmer-friendly.

	Eric

Received on Tuesday, 19 April 2011 03:49:29 UTC