I think this is an interesting idea. My big concern is with performance, though: the primary reason for IDOM was to improve the poor performance of DOM. We would need to evaluate performance tradeoffs of your proposed changes in order to determine whether the increased opaqueness is worth the pain.
Is this something you’ve implemented? Do you have any means of generating comparative performance data?
-jdb
On 2/19/02 2:36 PM, "Lenny Hoffman" <[EMAIL PROTECTED]> wrote:
Hi All,
I changes I proposed and submitted (IDOM/DOM integration) should be considered here. Making the current IDOM and its interface standard will fix its memory model, which makes it hard to have alternative implementations. Having the flexibility to plug in different implementations while maintaining a consistent external interface not only helps folks like me who are creating DOM adapters to existing OO interfaces, but also make it easier for the Xerces group to evolve the implementation as it sees fit for performance without having to maintain parallel interfaces like it has in the past (DOM and IDOM). In general, I believe it unwise to standardize a memory model.
Here is the summary I provided for Bugzilla #5967:
The DOM interfaces have lightweight smart pointers to referenced counted
implementation objects, while the IDOM interfaces eliminate the smart pointer
and the reference counting. The 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.
If the IDOM is standardized as is, I loose the ability to have a standard C++ DOM interface to my product. I simply can't keep all that is behind the DOM interface in memory at once, and I need the indirection provided by DOM instances to keep track of what is in use and what can be discarded. To facilitate this I added "addRef" and "removeRef" methods to IDOM_Node that my implementation can use, but are simply ignored by the current Xerces IDOM implementation.
If the IDOM/DOM integration is accepted, then no renaming has to occur, and the "I" in "IDOM" can be thought to represent Implementation, for that is what the role of all IDOM classes have become after the change. The primary interface remains through the DOM classes and and offers the greatest degree of backwards compatibility. Note that the way I made the changes that current users of IDOM are unaffected, and if the DOM interface is standardized than all that would happen to them is that they are not using the standard interface, which they is their current situation anyway. Meanwhile, they can adopt the DOM interfaces at their leisure without any noticeable performance degradation.
Regards,
Lenny
