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

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

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

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
objects.

______________________________________
Joe Kesselman  / IBM Research

Received on Thursday, 2 August 2001 10:10:10 UTC