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

On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> 1. Make "loadend" not fire in case a new load is started from
>>> onabort/onload/onerror. Thus "loadend" and "loadstart" isn't always
>>> paired up. Though there is always a "loadend" fired after every
>>> "loadstart".
>>> 2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also
>>>
>>> leaves the problem unsolved for XHR.
>>>
>>> Are there other options I'm missing?
>>
>> Or do both, improving XHR as much as backwards-compatibility allows and
>> don't try to match other APIs to it exactly.  I'd much prefer weirdness be
>> isolated to XHR than be perpetuated through every PE-based API.
>
> So what exactly are you proposing we do for XHR and for FileReader/FileWriter?
>
> I'm still not convinced that it's better for authors to require them
> to use setTimeout to start a new load as opposed to let them restart
> the new load from within an event and cancel all following events. I
> agree that this introduces some inconsistency, but it only does so
> when authors explicitly reuses a FileReader/XHR/FileWriter for
> multiple requests.
>
> 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.

I'm for this.  It lets FileReader and FileWriter match XHR, avoids [in
the odd case] long strings of stacked-up loadend events, and users can
avoid all the issues either by creating a new FileReader or by
wrapping nested calls in timers if they care.  I believe Jonas is in
favor of this as well.

Can we put this one to bed?

     Eric

Received on Wednesday, 2 November 2011 16:57:21 UTC