Re: [UndoManager] Re-introduce DOMTransaction interface?

On Thu, Jul 5, 2012 at 7:15 AM, Adam Barth <w3c@adambarth.com> wrote:

> On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay <Olli.Pettay@helsinki.fi>
> wrote:
> > On 07/05/2012 08:00 AM, Adam Barth wrote:
> >> On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay <Olli.Pettay@helsinki.fi>
> >> wrote:
> >>> On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
> >>> So, it is very much implementation detail.
> >>>
> >>> (And I still don't understand how a callback can be so hard in this
> case.
> >>> There are plenty of different kinds of callback objects.
> >>>   new MutationObserver(some_callback_function_object) )
> >>
> >> I haven't tested, by my reading of the MutationObserver implementation
> >> in WebKit is that it leaks.  Specifically:
> >>
> >> MutationObserver --retains--> MutationCallback --retains-->
> >> some_callback_function_object --retains--> MutationObserver
> >>
> >> I don't see any code that breaks this cycle.
> >
> > Ok. In Gecko cycle collector breaks the cycle. But very much an
> > implementation detail.
> >
> >> DOM events
> >
> > Probably EventListeners, not Events.
> >
> >> have a bunch of delicate code to avoid break these
> >> reference cycles and avoid leaks.  We can re-invent that wheel here,
> >
> > Or use some generic approach to fix such leaks.
> >
> >> but it's going to be buggy and leaky.
> >
> > In certain kinds of implementations.
> >
> >> I appreciatie that these jQuery-style APIs are fashionable at the
> >> moment, but API fashions come and go.  If we use this approach, we'll
> >> need to maintain this buggy, leaky code forever.
> >
> > Implementation detail. Very much so :)
>
> Right, my point is that this style of API is difficult to implement
> correctly, which means authors will end up suffering low-quality
> implementations for a long time.
>
> On Thu, Jul 5, 2012 at 2:22 AM, Olli Pettay <Olli.Pettay@helsinki.fi>
> wrote:
> > But anyhow, event based API is ok to me.
> > In general I prefer events/event listeners over other callbacks.
>
> Great.  I'd recommend going with that approach because it will let us
> provide authors with high-quality implementations of the spec much
> sooner.
>

The downside of events is that they have a higher overhead than we
originally thought was acceptable for mutation events (e.g. just computing
the ancestor chain is too expensive). Now that we fire less frequently, the
overhead might be OK, but it's still not great IMO.

Only having a high-overhead option for any new APIs we add is problematic.
I appreciate the implementation complexity concern, but I think we just
need to make callbacks work.

We could fire the event on the MutationObserver itself. That would be
lightweight. That doesn't help though, right?

new MutationObserver().addEventListener('onMutation', function()
{}) vs. new MutationObserver().observe(function() {})