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: Eric U <ericu@google.com>
Date: Wed, 21 Sep 2011 15:51:22 -0700
Message-ID: <CAHvSExfG9c_AA0ZJDibTvbdbq23UQPBFXJdi-c9+=9yut48T2w@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
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 3:29 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 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".

While it's certainly not hard to work around, as you say, it seems
more complex and less likely to be obvious than the
counter-for-activity example, which feels like the classic push-pop
paradigm.  And expecting users to write their event handlers one way
for XHR and a different way for FileReader/FileWriter seems like
asking for trouble--you're going to get issues that only come up in
exceptional cases, and involve a fairly subtle reading of several
specs to get right.  I think we're better off going with consistency.

>> 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:52:01 GMT

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