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

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