[gdome] Future development of gdome

[Raph Levien <raph acm org>]

Hi gdomers,

   Mathieu brings up a number of issues we've been considering for
getting Gdome to a shippable state.

   There are two proposals on the table. Both simplify the codebase
somewhat, but both also require some reworking of the code.

   The first proposal is to abandon using gnome-xml structures (such
as xmlNode) in favor of our own. Our structures would be _almost_ the
same as gnome-xml's, but with a couple of important differences:

   1) They would contain gdome-specific fields such as listener lists,
      so that we don't have to maintain separate Gdome_xml_Node data
      structures in addition to xmlNode.

   2) All DOM interfaces that derive from Node would actually _be_
      nodes.

   The second proposal is to get rid of the object oriented dispatch
of gdome functions. Under this proposal, a function like
gdome_n_firstChild() would be implemented directly. As mathieu points
out, this would require switching on node->type in some cases. I think
the amount of this code would be rather minimal.

   Now, to my analysis of the changes.

   The biggest improvement from using our own data structures is to
avoid the three-way special casing of the implementations of basic DOM
methods for each of the three major structures that implements a Node
interface (xmlNode, xmlAttr, and xmlDoc). The code duplication now is
not too bad, because (1) many of these methods are not implemented,
and (2) the event stuff is not there yet. Avoiding this duplication is
the major motivation.

   Using our own data structures would avoid inconsistencies between
the gnome-xml data structures and DOM. In particular, gnome-xml uses
hashtables to store dtd items, while DOM requires a list structure.
It's possible to change gnome-xml to fix this (and is in fact a
wishlist bug: http://bugs.gnome.org/db/51/5190.html).

   Finally, we'll simplify a bit some of the memory management and
bookkeeping for simply keeping track of the links between gnome-xml
and gdome.

   On the downside, we'll have to write code to bring an XML document
into a DOM tree. I think the cleanest way to do this is write a SAX
client that builds the tree using DOM methods. As a side effect, we
would gain independence from the XML parser. I agree with Mathieu,
though, that since gnome-xml is so good, this isn't a serious
advantage.

   Also, we'd need to adapt most of the methods in gdome. I think most
of the changes will be simple, straightforward, and stereotyped. The
"meat" of the operations would stay the same.

   The second proposal is only worth considering if the first is
adopted. In general, there won't be much need for object oriented
dispatch. However, after thinking about it some more, I really don't
want to lose the flexibility. The cost of an oo dispatch is pretty
minimal, and we _may_ want to do things like remote DOM access in the
future.

   I honestly don't know which way to proceed. The code duplication
for base DOM operations bothers my sensibilities a lot, but on the
other hand I'm reluctant to throw stuff away that's pretty close to
usable. Thoughts are welcome.

Raph