- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 3 Oct 2011 19:32:55 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Eric U <ericu@google.com>, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> So what exactly are you proposing we do for XHR and for >> FileReader/FileWriter? > > For APIs other than XHR, don't allow calling read* or abort during events > fired on the object from its own algorithms. This should give the guarantee > that loadstart and loadend will always be paired and non-interleaved, and > give developers a simple rule: if you need to start a new operation from > these events, push it into a timer (queue a task). > > (More precisely, no method that starts or finishes a loadstart/loadend > sequence can be called from within an algorithm that also starts or finishes > a sequence. abort() from within onprogress is fine, for example.) I think this is a higher cost to developers than the cost of having "loadstart" always be paired up with exactly one "loadend". Note that this would mean that you also couldn't start a new load from within the "loadend" event since that would cause event listeners after yours to receive interleaved loadstart/loadend events. The main problem here is actually the fact that "loadend" is fired synchronously from read*. If we removed that constraint then we could allow loads to start from anywhere without having to worry about interleaved loadstart/loadend. But it's somewhat doubtful that we can make such a big change to FileReader given that it's been in the wild for a while :( / Jonas
Received on Tuesday, 4 October 2011 02:33:52 UTC