W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Eric Uhrhane <ericu@google.com>
Date: Wed, 6 Apr 2011 15:37:57 -0700
Message-ID: <BANLkTimBxudbPufmbTOewa8Ls5f_84jg3g@mail.gmail.com>
To: James Robinson <jamesr@google.com>
Cc: Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org
This is now resolved.

On Fri, Dec 10, 2010 at 3:30 PM, Eric Uhrhane <ericu@google.com> wrote:
> 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 Wednesday, 6 April 2011 22:38:43 GMT

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