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

Re: Mutation events replacement

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Wed, 20 Jul 2011 22:10:32 +0200
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: public-webapps@w3.org
Message-ID: <er8e275l56grc4hoobb0thojukfqgfkb52@hive.bjoern.hoehrmann.de>
* Boris Zbarsky wrote:
>On 7/20/11 2:19 PM, Bjoern Hoehrmann wrote:
>> Depending on the design of the mutation notification system and what
>> level of complexity people find palatable, it would naturally also be
>> possible to serialize lazily
>
>The only way to do that is to make sure the pre-mutation data is kept 
>somewhere.  Doing that is _expensive_.  We (Gecko) have been there, done 
>that, and moved away from it.

Simple example: you get a notification whenever a script could observe
the .getAttribute value changes, and you get it before the change is
applied. Then you have all the data you need without expending effort on
that: you have the "old" state directly, and you know what change you're
about to make; the serialization code would just have to be able to pro-
duce a string assuming certain changes were made (which may be easy or
hard depending on implementation details).

Not a suggestion, but with the idea being to re-design the system from
scratch, it does seem important to understand that the cost here is not
coming from offering old and new values while notifying about changes,
but from the combination of doing that and other design decisions like
notifying after applying changes, allowing notifications to trigger new
changes, and so on. We got here from confusion about why it's expensive.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Wednesday, 20 July 2011 20:10:37 GMT

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