- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 6 Apr 2011 15:37:57 -0700
- 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 UTC