W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [UndoManager] Re-introduce DOMTransaction interface?

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 05 Jul 2012 20:11:03 +0300
Message-ID: <4FF5CAA7.2040404@helsinki.fi>
To: Ojan Vafai <ojan@chromium.org>
CC: Adam Barth <w3c@adambarth.com>, Ryosuke Niwa <rniwa@webkit.org>, public-webapps <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Ehsan Akhgari <ehsan@mozilla.com>, Erik Arvidsson <arv@chromium.org>, Sukolsak Sakshuwong <sukolsak@gmail.com>, Aryeh Gregor <ayg@aryeh.name>
On 07/05/2012 08:01 PM, Ojan Vafai wrote:
> On Thu, Jul 5, 2012 at 7:15 AM, Adam Barth <w3c@adambarth.com <mailto:w3c@adambarth.com>> wrote:
>
>     On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay <Olli.Pettay@helsinki.fi <mailto: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 <mailto: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 <mailto: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() {})

MutationObserver ctor takes the callback, not observe().

We're certainly not going to change MutationObserver callback handling.
MutationObserver is already unprefixed and all.
And in MutationObserver case having just one callback object per observer keeps things easier.
In many other cases the possibility for many callbacks (eventlisteners) is preferred.


But about UndoManager, I'd like to see the proposal how to handle transactions using events.



-Olli
Received on Thursday, 5 July 2012 17:11:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:53 GMT