W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [FileAPI] Result of calling MultipleReads on FileReader

From: Eric Uhrhane <ericu@google.com>
Date: Wed, 30 Mar 2011 11:01:25 -0700
Message-ID: <BANLkTimy5VQgO4nW1Jp2T8Xj-LsVr6-ZLg@mail.gmail.com>
To: Adrian Bateman <adrianba@microsoft.com>
Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>, Arun Ranganathan <aranganathan@mozilla.com>
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.

> Thanks,
> Adrian.
> --
> Adrian Bateman
> Program Manager - Internet Explorer - Microsoft Corporation
> Phone: +1 (425) 538 5111
> Email: mailto:adrianba@microsoft.com
Received on Wednesday, 30 March 2011 18:02:15 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC