Re: [FileAPI] Result of calling MultipleReads on FileReader

Eric, Adrian,


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:
>> As we continue to experiment with the File API, I'm trying to understand the
>> rationale for the Multiple Reads section:
>> http://dev.w3.org/2006/webapi/FileAPI/#MultipleReads
>>
>> The spec says:
>>
>>    If multiple read methods are called on the same FileReader object, user
>>    agents MUST only process the last call to a read method, which is the
>>    call that occurs last in a script block that has the "already started"
>>    flag set [HTML5].
>>
>> I'm trying to understand the rationale for respecting the LAST call - is it
>> common for people to call read lots of times and want the last one to be
>> respected. Since the read happens asynchronously, we'd rather kick off the
>> read operation as soon as the first read is called and give an error to
>> subsequent read calls. I'm not sure what the use case is for wanting the last
>> one (you can always call abort() and start again).
>>
>> 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.

-- A*

Received on Thursday, 31 March 2011 17:19:10 UTC