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<d...@w3.org> http://www.w3.org/People/Raggett
