- From: Raph Levien <raph@acm.org>
- Date: Fri, 03 Dec 1999 09:45:00 -0800
- To: Chris Lilley <chris@w3.org>
- CC: www-svg@w3.org
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