Re: Mutation events replacement

On Fri, Jul 1, 2011 at 12:43 PM, David Flanagan <dflanagan@mozilla.com> wrote:
> On 7/1/11 12:13 PM, Boris Zbarsky wrote:
>>
>> On 7/1/11 3:05 PM, David Flanagan wrote:
>>>
>>> I don't think I really explained my use case on this list. See
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c23 and
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c25
>>
>> And https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c26 please....
>>
> Yes, that too.  I agree that my use case is different than the one that
> Olli's proposal is addressing.  But Ryosuke asked about my use case :-)
>
>> > Similarly, I've found it important to
>>>
>>> be able to distinguish between nodes that are being removed from a
>>> document tree and nodes that are being moved within the document tree,
>>
>> Interesting, given that Gecko's DOM implementation does NOT make such a
>> distinction at the moment.  Why did you find this to be important?
>>
> As I see it, the test of sufficiency of set of mutation event is if you can
> use them to mirror a document tree. And in my case I'm trying to do that
> across a process boundary where I can't share nodes--I have to serialize
> everything to a string or something similar.  If I call appendChild() on a
> node that is already in the tree, that removes it from its current parent
> and inserts it into a new parent.  If that generates a remove event and then
> an insert event I'll end up having to completely re-serialize the node (and
> all of its children) to re-insert it from scratch into the mirror tree.  If
> the appendChild() generates a move event then I can simply serialize the
> fact that an existing node has moved.  There are probably ways I could make
> this work without a move event, but that's why I found it useful to make the
> distinction.

To clarify: Are you worried that it isn't possible to detect the move
and avoid serializing the non-novel node without the "move"
information in the underlying mutationList? Or are you concerned that
detecting this is work and it might be good to just provide the
information and remove the need for the observer to do that work?

Your point about the sufficiency test being mirroring a tree seems
exactly right to me. I may be missing something, but I think "move"
isn't strictly necessary.

>
>>> Implementations will presumably maintain one list of all current
>>> mutations, and then will have to filter that list to deliver only those
>>> that match the desired type and desired subtree for which a listener is
>>> registered.
>>
>> That's unclear.  Maintaining this list (if it were done) sounds very
>> expensive; in Gecko's case we're more likely to drop on the floor the ones
>> which have no registered listeners.
>>
> Sure, but if there were multiple listeners on different subtrees, listening
> for different types of events, would you
> built up a custom mutation list for each one as the mutations were occuring?
>  Or build up one master list and then filter it lazily when the events are
> dispatched?
>
>    David
>>
>> -Boris
>
>
>

Received on Friday, 1 July 2011 21:07:11 UTC