On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard <gl...@zewt.org> wrote: > On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking <jo...@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