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: James Robinson <jamesr@google.com>
Date: Fri, 10 Dec 2010 15:17:42 -0800
Message-ID: <AANLkTin5mCBznGAOfSuVFtFZv5Yp0CM9HtSQL5EzgWqh@mail.gmail.com>
To: Eric Uhrhane <ericu@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 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 <sysbot%2Btracker@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.

- James

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

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