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

Re: ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer]

From: Eric Uhrhane <ericu@google.com>
Date: Fri, 10 Dec 2010 15:30:37 -0800
Message-ID: <AANLkTinbWdnZv72wk275=TbF8t_EZ0_AGaOzhncj9PEb@mail.gmail.com>
To: James Robinson <jamesr@google.com>
Cc: Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org, Web Applications Working Group Issue Tracker <sysbot+tracker@w3.org>
On Fri, Dec 10, 2010 at 3:17 PM, James Robinson <jamesr@google.com> wrote:
> On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane <ericu@google.com> wrote:
>>
>> On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>> > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue
>> > Tracker <sysbot+tracker@w3.org> wrote:
>> >>
>> >> ISSUE-173 (ericu): terminal FileWriter progress events should be queued
>> >> [File API: Writer]
>> >>
>> >> http://www.w3.org/2008/webapps/track/issues/173
>> >>
>> >> Raised by: Eric Uhrhane
>> >> On product: File API: Writer
>> >>
>> >> When a FileWriter successfully completes a write, currently it:
>> >> * dispatches a write event
>> >> * sets readyState to DONE
>> >> * dispatches a writeend event
>> >>
>> >> If you want to start a new write, you can't do it in onwrite, since
>> >> readyState is still WRITING.  Those events should be queued for
>> >> asynchronous
>> >> delivery, so that readyState is DONE by the time they get handled.  If
>> >> you
>> >> set up a new write in onwrite, you'll still run the risk of getting
>> >> confused
>> >> by the subsequent writeend from the previous write, but that's
>> >> detectable.
>> >>
>> >> I'll have to look and see what other events should be marked as queued.
>> >
>> > Why not queue a task that changes readyState and then dispatches write
>> > followed by writeend, "synchronously" from the task. That is how a
>> > number of
>> > things work in XMLHttpRequest.
>>
>> That would work too.  Any reason that you don't want to set readyState
>> before queueing the task?  This is already happening asynchronously,
>> in response to the write finishing--the important thing is just to
>> make sure the events are queued, and readyState is updated, before the
>> first handler runs.
>
> I'm not familiar with this particular API, but in general I think it's
> important that state variables be set at the same time that the relevant
> event fires.  In other words, code that polls readyState or similar
> attributes should not be able to observe any change before the related event
> is fired.

Yeah, that makes sense [+thanks to Jonas for pointing this out
off-list].  I'll link the readyState change with onwrite in the
success case and onerror in the failure case, then have onwriteend
come after.

> - James
>>
>> > --
>> > Anne van Kesteren
>> > http://annevankesteren.nl/
>> >
>> >
>>
>
>
Received on Friday, 10 December 2010 23:31:22 GMT

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