W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

Re: Semi-OT: Where To Go...

From: Joseph Kesselman <keshlam@us.ibm.com>
Date: Thu, 2 Aug 2001 10:09:30 -0400
To: "'WWW-DOM List'" <www-dom@w3.org>
Message-ID: <OF3141F50D.F68C922A-ON85256A9C.004CD1BF@pok.ibm.com>

> Now what I want to know is how the
>implementations are actually doing it

In some implementations, that's going to be considered proprietary

In others, you can not only ask how it's being done -- you can SEE how it's
being done. For example, the Apache Xerces project includes a DOM
implementation (actually, I think it now has at least two such
implementations)... and Xerces is open-source. There are others which will
let you examine their solution in detail.

I haven't rechecked the current implementation, but when I first wrote that
code for Xerces the NodeList was treated essentially as an
incrementally-built cache. The main DOM tree was provided with a way to
indicate that something within a node's subtree had changed -- you can
think of it as a "dirty bit", though in fact it was a counter -- and each
access to NodeList checked whether this had been altered since the last
NodeList request and if so flushed the cache and forced the NodeList to
recompute itself. If the document hadn't changed, this was fast; if it had,
it was slow but Did The Right Thing. Downside is that every document
mutation operation has to be instrumented to update the dirty flag.

If your DOM supports Level 2 Events, this would be another possible
approach. There's a problem with that solution, in that Level 2's mutation
events could be cancelled before they reached the NodeList's event handler,
DOM Level 3 is looking at adding a "listener group" mechanism so
cancellations only affect listeners within the same group; you could use an
informal prototype of that solution to bridge this gap.

I'm sure there are other solutions. Pick one that works for you. One thing
to watch out for: Remember to consider memory-management issues; some of
the alternative solutions we looked for Xerces at had a risk of leaking

Joe Kesselman  / IBM Research
Received on Thursday, 2 August 2001 10:10:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:08 UTC