W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 3 Oct 2011 19:32:55 -0700
Message-ID: <CA+c2ei8tQQFcSS4UjBoSa+9DrmyeJgZNnEKve4iz4S0q5OBT9Q@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Eric U <ericu@google.com>, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> So what exactly are you proposing we do for XHR and for
>> FileReader/FileWriter?
> For APIs other than XHR, don't allow calling read* or abort during events
> fired on the object from its own algorithms.  This should give the guarantee
> that loadstart and loadend will always be paired and non-interleaved, and
> give developers a simple rule: if you need to start a new operation from
> these events, push it into a timer (queue a task).
> (More precisely, no method that starts or finishes a loadstart/loadend
> sequence can be called from within an algorithm that also starts or finishes
> a sequence.  abort() from within onprogress is fine, for example.)

I think this is a higher cost to developers than the cost of having
"loadstart" always be paired up with exactly one "loadend".

Note that this would mean that you also couldn't start a new load from
within the "loadend" event since that would cause event listeners
after yours to receive interleaved loadstart/loadend events.

The main problem here is actually the fact that "loadend" is fired
synchronously from read*. If we removed that constraint then we could
allow loads to start from anywhere without having to worry about
interleaved loadstart/loadend.

But it's somewhat doubtful that we can make such a big change to
FileReader given that it's been in the wild for a while :(

/ Jonas
Received on Tuesday, 4 October 2011 02:33:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC