Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Wed, Sep 21, 2011 at 6:14 PM, Eric U <ericu@google.com> wrote:

> If we eliminate it entirely, then you can't ever start a new read on
> the same object from the abort handler.  That seems like a reasonable
> use case.
>

It's trivial to stuff it into a zero-second timeout to knock it out of the
event handler.  This is such a common and useful pattern that libraries have
shorthand for it, eg. Prototype's Function#defer.  I don't think that's an
onerous requirement at all; it's basically the same as specs saying "queue
an event".

Adding a number-of-reads-outstanding counter isn't that much more
> code.


It's not much more code, but it's code dealing with a case that doesn't have
to exist, working around a very ugly and unobvious sequence of events, and
it's something that you really shouldn't have to worry about every single
time you use loadstart/loadend pairs.

And if you're really trying to keep things simple, you're not
> aborting and then starting another read during the abort, so the above
> code works in your app.
>

The above code and the code triggering the reads might not even be written
by the same people--the activity display might be a third-party component
(who very well might not have thought of this; I wouldn't have, before this
discussion).

-- 
Glenn Maynard