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 GMT

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