On 3/31/11 6:12 PM, Eric Uhrhane wrote:
On Thu, Mar 31, 2011 at 2:55 PM, Adrian Bateman<adria...@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<adria...@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*
