- From: Kartikaya Gupta <lists.webapps@stakface.com>
- Date: Fri, 18 Jul 2008 13:31:44 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, 17 Jul 2008 17:51:42 -0700, Jonas Sicking <jonas@sicking.cc> wrote: > > As for when the events fire (note that this is just clarifications of > the spec, not changes to it): > For events that fire after the mutation takes place I propose that we > add a concept of a "compound operation" and state that while compound > operations are in progress no mutation events are fired. I was thinking about this some more, and it seems to me that a "compound operation" is more or less a lightweight transaction (transaction in the sense that is referred to in 1.6.4 of L2 events). It might be useful to expose this functionality to authors as well. If a couple of methods were added to allow authors to indicate the start and end of a compound operation/transaction, and it were guaranteed that no mutation events would be dispatched until the end of the compound operation, they would have to worry less about dealing with interference from other mutation listeners while they're doing a high-level compound operation. It would be pretty trivial to implement on top of internal compound events, and would solve the problem of revalidating assumptions for authors as well as implementors. The only pitfall I can see is if authors started a compound operation and never ended it, causing an unbounded queue of events. We'd have to allow implementations to drop the queue (or some events) if it got too large. Thoughts? kats
Received on Friday, 18 July 2008 13:32:23 UTC