Re: Mutation events replacement

On 02/07/11 15:07, Boris Zbarsky wrote:
> On 7/2/11 6:28 AM, Dave Raggett wrote:
>> My use case involves multiple people simultaneously editing the same
>> document. The mutations due to user actions are batched and serialized
>> as JSON. If you know that a given node was moved then you can avoid the
>> overhead of serializing a full description of its attributes and
>> content, as is necessary when describing a node to be inserted.
>
> OK, that's similar to David's use case.  Do we have any data on how 
> common the "move" pattern is compared to the "remove and insert" 
> pattern?  That is, does having such an optimization help in practice?
>
>> If the browser is able to build a list of all the mutations involved in
>> a given user action, this would presumably be more efficient than
>> leaving this to web page scripts to do.
>
> Well, sure, for the cases when web script would build such a list.  Is 
> that the common case for mutation consumers?
>
> For Gecko's internal mutation consumers, this is NOT a common case; 
> the vast majority of them just want to know that "something changed" 
> because attempting to synchronize state is too complicated to be worth 
> it in most of those cases.  An exception is the code managing the CSS 
> box tree, but this has other requirements as well (and is _very_ 
> complicated because it's considered performance-critical).
>
>> It is critically important to know what nodes have been inserted,
>> removed, moved, or have had their attributes changed.
>
> For some use cases, this is a useful optimization, yes.  Are those 
> cases the common case?
>
>> If all you know is that some of the children have changed for a given 
>> node, the script has
>> to do a lot of work to find out which have changed and in what manner,
>> and this will probably involve keeping a local duplicate of the DOM tree
>> at considerable cost.
>
> That may be ok, if the use cases that incur this cost are rare and the 
> common case can be better served by a different approach.

If you have used Google Docs for minute taking in teleconferences, you 
won't  want to go back to older ways of taking minutes since it allows 
every one present to make corrections and add to the minutes during the 
meeting. Live concurrent editing of DOM trees for shared editing is 
compelling for real time collaboration and works with today's 
implementations of mutation events.

Of course, having a flag to ask for the full list would be fine, but 
having to  keep a duplicate DOM tree and do an expensive search to 
figure out what changes had occurred would be a retrograde step and harm 
the new wave of real-time collaborative web applications.

> Maybe we need both sorts of APIs: one which generates a fine-grained 
> change list and incurs a noticeable DOM mutation performance hit and 
> one which batches changes more but doesn't slow the browser down as 
> much...

That would be fine.

-- 
  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett

Received on Saturday, 2 July 2011 15:53:05 UTC