Re: [FileAPI] Result of calling MultipleReads on FileReader

On 3/31/11 6:12 PM, Eric Uhrhane wrote:
> 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.

Eric: are you sure you mean "throw" or do you mean, fire error event or 
abort?  Note that only FileReaderSync (running on threads) actually 
"throws" in terms of an exception.
>> 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.
>

Eric: can you be a bit more explicit about what you mean by "illegal?"  
I'm fully on board with being more explicit BTW, and want to address 
Adrian's nits (and yours) in an update to the specification.

-- A*

Received on Monday, 11 April 2011 15:28:49 UTC