Eric, Adrian,
On 3/30/11 2:01 PM, Eric Uhrhane wrote:
On Mon, Mar 28, 2011 at 5:37 PM, Adrian Bateman<adria...@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*
