Re: [gdome] Future development of gdome

[Raph Levien <raph acm org>]

Ok, DV has put forth strong arguments for modifying gnome-xml to make
life better for gdome.

This approach has one killer advantage: gnome-xml and gdome being able
to share functionality.

However, it also has the problem of requiring more coordination. Among
other things, this means that gdome is stuck until gnome-xml 2.0
starts to happen. I don't consider this a showstopper, but it still
feels a bit frustrating. Gdome has been stuck for one reason or
another for quite some time now, and Gill because of it.

Nonetheless, I'm very willing to work with DV on unifying the
approaches. Here's an outline of changes I suggest which will
maximally help gdome while minimally affecting existing apps that use
gnome-xml.

First, as many Node-inheriting structures should be unified with
xmlNode as possible. These include xmlDoc, xmlDtd, and perhaps
individual dtd components. It would also be nice to unify xmlAttr.

Probably the easiest way to unify these structures is just to have a
common prefix. This allows the use of existing named fields in
existing code without difficulty.

Looking at the code, only type..last of xmlNode will need to be shared
with other structures. The remaining fields seem to be specific to
Element and CharacterData interfaces.

In order to facilitate mutation of the dtd, there should probably be a
call to "rehash" the hashtables from the child nodes. All
implementations of node mutation should check type == XML_DTD_NODE (I
think) and rehash if needed.

DV asked about the two fields originally intended as CORBA headers.
Gdome is currently using _private as a link to nodes reflected in
Gdome. I should clarify this: each xmlNode is either reflected or not.
If reflected, then _private points to a Gdome_xml_Node, which also has
an n field pointing to the xmlNode. If not reflected, then the
_private field is NULL. The Gdome_xml_Node structure contains a
reference count and a listener list.

I am not presently using the vepv link.

The reference counting in gdome is not quite right yet. In particular,
it's still not safe to remove nodes just because they have no parent
and the reference count goes to zero. The reason it is not safe is
that there may be reflected nodes (with nonzero reference count) that
can reach this node by following parent links. I am confident that
this problem can be solved, but will require an additional "upwards"
reference count field of some kind. I have not yet worked out the
details. I will probably just add this field to the Gdome_xml_Node
structure, and force all nodes from the no-parent root down to the
referenced node to be reflected. It may be more efficient in some
cases to add this field to the xmlNode, at the cost of more memory
usage in the non-Gdome case, of course. I will think about it some
more.

Raph