- From: Eric U <ericu@google.com>
- Date: Wed, 21 Sep 2011 15:51:22 -0700
- 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 UTC