- From: Raph Levien <raph@acm.org>
- Date: Fri, 03 Dec 1999 09:00:36 -0800
- To: Chris Lilley <chris@w3.org>
- CC: www-svg@w3.org
Chris Lilley wrote: > > It would be very helpful for the Document Object Model (DOM) working > group to know of all DOM implementations - in particular, > implementations of (perhaps part of) DOM 2 - that are available, in this > case for implementing SVG. > > I know what XML parser some implementations use, in other cases I do > not. In some cases, the DOM is provided by the XML parser or by the CSS > parser (in the case of DOM2 CSS OM), in other cases a separate component > is used. > > I am calling on all SVG implementors to let me know which parts of DOM 1 > and DOM 2 they implement, or plan to implement in the coming months, so > that I can report this back to the DOM working group. Implementation > feedback (this part hard to understand, not sure what that part is for, > etc) would also be good at this time. > > Responses should be sent to this list, or if desired can be sent to me > privately at chris@w3.org. Gill uses our own homegrown DOM implementation, Gdome. 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. Gdome is written in C (as is the rest of Gill - the SVG implementation page incorrectly has it as C++). 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. 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. Further, Gdome is based on UTF-8 rather than UTF-16 encodings. We've played around with CORBA bindings (including, for example, translating the encoding), but at this point don't feel that DOM over CORBA is a good solution, due to the distributed garbage collection and latency problems. Hope this is helpful. Raph P.S. I know the Gill webpage is a bit out of date. However, development is still going strong. Right now, I'm focussing on making libart (the 2D graphics engine powering Gill) more robust. I'll be giving a talk on Gill at Linux Expo Paris 3 Feb 2000, if anyone is interested.
Received on Friday, 3 December 1999 12:00:17 UTC