Re: [gdome] Future development of gdome

[Daniel Veillard <Daniel Veillard w3 org>]

On Tue, Jan 25, 2000 at 12:06:57PM -0800, Raph Levien wrote:
> 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.

  3 approaches possible:
     - use a different CVS base, like the one at W3C for
       the libxml version with tweakings
     - for a stable gnome-xml branch and break compatibility in the
       head
     - declare that libxml-1.8.5 is the last version of the 1.X series
       and don't even bother to maintain it


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

  agreed, this is also beginning to cause me pain in XPath.

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

  don't forget namespace. Most of the elements are named too.

  I suggest the following common prefix:

    void           *_private;   /* application specific */
    xmlElementType   type;      /* but open to extensions  */
    struct _xmlDoc  *doc;       /* the containing document */
    struct _xmlNode *parent;    /* child->parent link */
    struct _xmlNode *next;      /* next sibling link  */
    struct _xmlNode *prev;      /* previous sibling link  */
    struct _xmlNode *children;  /* parent->list of children link */
    struct _xmlNode *last;      /* last child link */
    const xmlChar  *name;       /* the name of the node, or the entity */
    xmlNs          *ns;         /* pointer to the associated namespace */


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

  Why not just a call to Add and a call to Remove ?

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

  Ok, I don't think more than one private field is needed

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

  Humm, can't this info be added to the private field anyway ?

Daniel

-- 
Daniel Veillard w3 org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
 http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe