W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 21 Sep 2011 18:29:46 -0400
Message-ID: <CABirCh_QAXx7L8H2VxPxkSYp2zSDq9SkkHGnHh5b3X3-AZKQ5w@mail.gmail.com>
To: Eric U <ericu@google.com>
Cc: Jonas Sicking <jonas@sicking.cc>, arun@mozilla.com, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org, Anne van Kesteren <annevk@opera.com>
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
Received on Wednesday, 21 September 2011 22:30:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT