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: Glenn Maynard <glenn@zewt.org>
Date: Mon, 3 Oct 2011 21:39:16 -0400
Message-ID: <CABirCh94_9bQr==3cAwJxbv03Hmt6DtBUWxJ78esspNcOJnWew@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
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 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 don't have a strong opinion about what to do with XHR--my main worry is
not perpetuating ugliness into every PE API in order to mimic XHR.

And it only weakens the invariant, not removes it. So instead of
> * There's exactly one 'loadend' event for each 'loadstart' event.
> we'll have
> * There's always a 'loadend' event fired after each 'loadstart' event.
> However there might be other 'loadstart' events fired in between.

When can this happen, with the above restriction in place (speaking of eg.
FileReader, not XHR)?

Glenn Maynard
Received on Tuesday, 4 October 2011 01:39:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:54 UTC