Re: [FileAPI] Result of calling MultipleReads on FileReader

On Mon, Apr 18, 2011 at 8:48 PM, Eric Uhrhane <ericu@google.com> wrote:
> 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.

I think it's pretty clearly 1. xhr.open selects what resource to load
(and how to load it), and xhr.send starts the loading.
FileReader.readAsX does both.

However I did realize one thing, which is that if we go with the
throwing behavior for now, we can always change to non-throwing later
if people complain about the inconsistency. Going the other way is
much harder.

So ultimately I'm fine with going either way.

/ Jonas

Received on Tuesday, 26 April 2011 00:36:01 UTC