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

Re: Mutation events replacement

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 20 Jul 2011 15:56:20 -0700
Message-ID: <CA+c2ei_ebpucoWNZq2_bgrtiVZN1bsk+yBK6qcU2D4dyGTnOog@mail.gmail.com>
To: Olli Pettay <Olli.Pettay@helsinki.fi>
Cc: public-webapps@w3.org
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 07/20/2011 06:46 PM, Jonas Sicking wrote:
>
>>>> Hence I'm leaning towards using the almost-asynchronous proposal for
>>>> now. If we end up getting the feedback from people that use mutation
>>>> events today that they won't be able to solve the same use cases, then
>>>> we can consider using the synchronous notifications. However I think
>>>> that it would be beneficial to try to go almost-async for now.
>>>
>>> I disagree.
>>
>> I had hoped for a bit more of an explanation than that ;-)
>>
>> Such as why do you not think that synchronous events will be a problem
>> for web developers just like they have been for us?
>
> In practice synchronous events have been a problem to us because we
> are in C++, which is unsafe language. Web devs use JS.

The only C++ specific problem that we've had is dangling pointers.
However only a small set of our problems would have been solved by
making local points strong.

We'd still have problems with indexes changing under us, and nodes
that we removed from one location now being inserted elsewhere, etc.

Another way to look at it is that due to C++ specific problems, when
unexpected things happen during callbacks, we end up possibly
crashing. In Javascript, if unexpected things happen during callbacks,
you'll get buggy behavior. That's better, but still not good.

> Web devs usually want something synchronous, like sync XHR
> (sync XHR has other problems not related to mutation handling).
> Synchronous is easier to understand.

That is a wholly different type of sync API. Those are APIs where the
return value is delivered through a callback rather than as a return
value, forcing you to create awkward code like:

doSomething(function(res1) {
  res1.callFunc(function(res2) {
    doSomethingElse(res2);
  }
}

There's a very good problem description here: http://tamejs.org/
(ignore the proposed solution, it's the problem description that's
interesting for this discussion).

Those problems aren't happening here as far as I can tell. There are
no return values delivered asynchronously, nor any of the problems
described in the tamejs page.

/ Jonas
Received on Wednesday, 20 July 2011 22:57:26 GMT

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