W3C home > Mailing lists > Public > www-svg@w3.org > December 1999

Re: DOM in SVG implementations

From: Chris Lilley <chris@w3.org>
Date: Fri, 03 Dec 1999 18:24:34 +0100
Message-ID: <3847FCD2.25466FBE@w3.org>
To: Raph Levien <raph@acm.org>
CC: www-svg@w3.org


Raph Levien wrote:
> 
> 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.

> Gill uses our own homegrown DOM implementation, Gdome. 

That is the one that Daniel Veillard helps with, yes?

> 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)

>  Gdome is
> written in C (as is the rest of Gill - the SVG implementation page
> incorrectly has it as C++).

Thanks, I will update it.

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

> 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?

> 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?

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

Very much so, thanks for taking the time to report back on your
findings.

> Raph
> 
> P.S. I know the Gill webpage is a bit out of date.

Somewhat, but I know how it goes.

>  However, development
> is still going strong. 

Yes. I found the CVS changelog on the Web, which is where the 'last
update' date on the SVG Implementation page comes from ;-)

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

Quite possible (I live in France, though South rather than Paris).

--
Chris
Received on Friday, 3 December 1999 12:24:39 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:18 GMT