Re: [Tclxml-devel] Tcl-DOM generic framework

[Steve B. <Ste...@zv...>]

Joe English wrote:
> It looks like integrating dom::c into the new Tcl-DOM
> generic framework is going to be more difficult than
> I first expected.  Also, there are some serious pitfalls
> in the generic implementation.

We're still in an alpha stage with that code, so changes/
suggestions are welcome.

> The main issue is that the generic layer checks the
> Tcl_Obj 'typePtr' field of DOM node objects to determine
> which DOM implementation created the node.  dom::c doesn't 
> actually use a separate Tcl_ObjType to represent nodes; 
> instead, it uses strings with handle semantics.

Yes, that didn't really work after all.  Object shimmering
blew that design out of the water :-(

I've changed the code recently to always use the
default implementation, falling back to the Tcl implementation
if it fails.

> (Using strings with handle semantics is actually the safest
> thing to do in the presence of [dom::DOMImplementation destroy].
> Using a custom Tcl_ObjType can lead to Tcl_Obj's with dangling
> pointers in their internal reps if you're not _extremely_ careful.)

TclDOM/libxml2 defines a string handle for an object, as well as
an internal rep.  I maintain a hash table of string reps,
so if the object loses its internal rep it can be retrieved
from the string rep.  This strategy allows faster performance
when the internal rep is preserved, but is still reliable.

I haven't fully resolved object destruction yet.

> Even if dom::c did use a custom Tcl_ObjType, there would still
> be a danger if multiple DOMImplementations are loaded into the
> same process.

My assumption was that having multiple implementations
simultaneously loaded might be useful for some applications.
Is that an incorrect assumption?  What if I wanted to
import nodes to/from a TclDOMPro tree into a (hypothetical)
e4graph-based DOM tree?

 >  It's very easy for the internal rep to be discarded,
> and there's no way to get from the string rep back to the
> DOMImplementation which created the node.

That's true, see above.

> If there's only one DOMImplementation registered, this
> problem won't be fatal (since the generic layer will just
> dispatch to the single, default, DOMImplementation), but if
> there are more than one the generic layer is likely to break
> badly.
> 
> I'm not sure how to fix this.

We may need to change the underlying design.  The problem
is allowing scripts to be portable between implementations.

Cheers,
Steve Ball

-- 
Steve Ball            |   XSLT Standard Library   | Training & Seminars
Zveno Pty Ltd         |     Web Tcl Complete      |   XML XSL Schemas
http://www.zveno.com/ |      TclXML TclDOM        | Tcl, Web Development
Ste...@zv...  +---------------------------+---------------------
Ph. +61 2 6242 4099   |   Mobile (0413) 594 462   | Fax +61 2 6242 4099