DOM_ IDOM_ Integration

[Lenny Hoffman <le...@earthlink.net>]

Hi All,

Can someone share what the plan is for IDOM?  It appears to be around and
stable for awhile -- the CVS repository shows last modified dates of at
least 6 weeks with most beyond two months.  How much longer is it going to
remain experimental, and is it supposed to replace the DOM_ interfaces?

While it is in the experimental state, though, to perhaps aid in the
integration of the two, and to allow for swappable back ends, I would like
to propose some refactoring.  The DOM interfaces have lightweight smart
pointers to referenced counted implementation objects, while the IDOM
interfaces eliminate the smart pointer and the reference counting.  My
proposal is simply to add lightweight smart pointers to the IDOM
implementation.  Reference counting is still eliminated, but the smart
pointers facilitate an interface that retains familiarity with the Java
version of xerces and allows for different back ends (implementations) to be
plugged in.  One back end would be the IDOM itself, while others could be
application specific adapters (for those that want to provide a DOM API to
their application), database adapters, etc.

Here is a crude attempt at some UML:

    -------------              -------------
    | DOM_Node  | -----------> | IDOM_Node |
    -------------              -------------

DOM_Node will let IDOM_Node know about the its attaching and detaching, and
those implementations of IDOM_Node that care to use that information can,
the current ones would not.  The type of backend would be chosen simply by
using the specific derivative of IDOM_DOMImplementation that creates the
desired type of IDOM_Document derived object, which of course is a factory
for its type of backend nodes.

What is interesting about this approach is that IDOM can still be used
directly via a different IDOM_DOMImplementation/IDOM_Document pair (if the
lightweight pointer is seen as too much overhead for some), and one of the
back ends could be the current DOM_ reference counted node implementations
(if desired for some reason).

The reason I bring this up is I am wanting to create a database adapter, I
like the IDOM approach, but need the indirection provided by a smart
pointer.  Along with providing a common interface for transient (read IDOM)
and persistent DOMS, I need the constructor/destructor of a smart pointer to
keep track of what nodes are currently in use.  Simply handing out a pointer
does not tell me when someone is done with it.  I need to support persistent
DOMs that are much larger than is practical to load in memory all at once,
and wish to employ lazy evaluation, where a node is loaded only when
accessed, and released when no longer used.

Please let me know if this is a bad idea for some reason, doesn't fit into
the vision for xerces, etc.

If viewed positively, I would be happy to contribute to the effort.

Thanks,

Lenny



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org