Re: DOM in SVG implementations

Chris Lilley wrote:
> 
> Raph Levien wrote:
> > Gill uses our own homegrown DOM implementation, Gdome.
> 
> That is the one that Daniel Veillard helps with, yes?

Gdome uses Daniel's libxml (aka gnome-xml) package to do the xml parsing
and most of the storage of DOM nodes (some of the DOM node state is
stored in structures maintained by Gdome itself). Daniel isn't deeply
involved with the Gdome codebase itself but helps quite a bit regarding
design and integration issues.

> > Our goals are to
> > be 100% core DOM1 compatible, and supply enough of the DOM2 functions
> > for our needs. Not all functionality is currently implemented.
> 
> Which parts of DOM 2 are implemented? For the unimplemented parts, is it
> because these are felt to be not useful, or is it the usual reasons (not
> enough hours in the day, etc)

A combination of the two.

The only DOM2 part that's implemented now is the event mechanism.
Namespace support will go in there soon, as that's apparently needed to
support XPath and friends properly.

> > My personal experience with DOM has been fairly negative so far. When I
> > started Gill, I was fairly enthusiastic about DOM, and took the approach
> > of basing the entire implementation around it. However, we ran into some
> > problems. The event model in DOM2 (last I checked) has serious
> > limitations that prevent it being really useful for the
> > Model/View/Controller pattern. Thus, we're looking at having to
> > implement nonstandard extensions to DOM2 so that Gill can have a clean
> > MVC architecture.
> 
> I would certainly be interested to hear any more detail about this.

The gory details are on the DOM working group public list. I don't think
they like me very much anymore :)

But in outline, here's the problem. DOM2 has an event propagation
mechanism (bubbling and capturing) that's pretty handy for implementing
a View. In this framework, each handler for a DOM element has a choice
of whether to attach an event listener to the node. If it does attach a
listener, then it is immediately notified of all changes to that node,
and takes responsibility for getting the display updated accordingly. If
not, though, the event bubbles up until it reaches a node for which
there is a handler attached (typically a <g> element). _That_ handler
just redisplays the child from scratch.

Thus, you can take advantage of being able to do incremental updates
when that's a win, but also avoid the complexities in other cases.

Note, alas, that I said "a View". The listener that actually handles the
event invokes the ::preventBubble() method on the event to prevent it
from bubbling upwards and causing unneeded redisplay. However, in the
current DOM2 spec, this method prevents bubbling in _all_ attached
listeners. Thus, it's entirely plausible that you'll have two views with
different patterns of attached listeners. The one that handles the event
lower in the tree will prevent the event from bubbling up to the correct
level in the other one, thus resulting in a missed update.

The DOM2 people seem to be quite aware of this problem, but unwilling to
fix it. C'est la W3C.

> > In addition, DOM per se has lots of potential garbage collection
> > problems and some other Java-isms. For Gdome, we added ::ref() and
> > ::unref() methods so that nodes could be reclaimed by reference
> > counting.
> 
> So once there are no remaining references the node can be deleted?

Exactly. Incidentally, we also added ::query_interface(), but at the
moment we're not actually using it (we experimented with implementing
multiple inheritance in C and found it to be pretty painful).

> > Further, Gdome is based on UTF-8 rather than UTF-16 encodings.
> 
> You mean, internally it is stored as UTF8 (which is fine) or do you
> mean, there isn't a UTF-16 interface available?

The former. The C API also uses UTF8, because we find it much easier to
deal with. However, the experimental CORBA bindings take care of the
conversion to UTF-16 transparently.

> > Hope this is helpful.
> 
> Very much so, thanks for taking the time to report back on your
> findings.

Glad to do so.

Raph

Received on Friday, 3 December 1999 12:44:39 UTC