Re: Fwd: XBL2: First Thoughts and Use Cases

On 12/16/10 1:46 PM, Tab Atkins Jr. wrote:
> On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarsky<bzbarsky@mit.edu>  wrote:
>> On 12/16/10 1:00 PM, Dimitri Glazkov wrote:
>>>
>>> I agree that it's going to be difficult to get this right, but
>>> semi-live templates (if you change it here, it will reflect on all
>>> instances, but it you change it here, it won't) seem even more
>>> fragile.
>>
>> Sure.  I'm proposing that templates be completely dead.  I'm also proposing
>> that, for a first cut, shadow trees be completely dead (in the "will throw
>> exception if you try to add or remove nodes" sense), unless we can figure
>> out how to efficiently implement live shadow trees.
>
> Hmm.  Olli just said that shadow mutations are common in XBL1.  I'm
> somewhat loathe to make it automatically dead.

OK.  I can see that.  Certainly a binding like Firefox's tabbrowser 
needs to be able to modify its DOM (e.g. to add the new tab)...

We could restrict this further by only disallowing mutations that affect 
output ports, but that could be confusing to spec and author to (though 
in practice, users of Mozilla XBL author under just such a restriction, 
in that if they do something that does affect output ports things break).

> On the other hand, there are lots of use-cases where dead shadows are
> perfectly fine, so having some declarative way to differentiate
> between whether the shadow needs to be live or dead might work.

Hmm.  Yeah, that might work.

> It sounds like it's fine for the shadow to mutate, so long as nodes
> aren't added/created/moved.

And removed, yes.

> For example, I can twiddle attributes on
> a shadow node without requiring the more expensive "map all the
> metadata out" step, right?

Yes.

> The idea is just that we can, as an optimization, keep all the metadata on a central shared object, so
> that any time I, say, add a normal-DOM node to a component, I can just
> go check that central data object to see where to forward the node?

Yep.

I suppose one could have a COW scheme where the metadata is cloned on 
mutation, but that requires a check on every mutation and makes it very 
easy to accidentally deoptimize...  Maybe that's ok.

-Boris

Received on Thursday, 30 December 2010 04:52:53 UTC