[XML-SIG] Re: [4suite] ReleaseNode interface in 4XSLT

[Uche Ogbuji]

Just a note: I'm guessing you intended to x-post this to xml-sig, not
python-dev.  I've changed the headers.

"Martin v. Loewis" wrote:
> 
> Currently, 4XSLT has a dependency on the DOM implementation in terms
> of memory management (among other dependencies). I'd like to reduce
> this dependency, by providing a centralized function that knows how to
> release nodes.
> 
> In PyXML, I currently use
> 
> # Define ReleaseNode in a DOM-independent way
> import xml.dom.ext
> import xml.dom.minidom
> def _releasenode(n):
>     if isinstance(n, xml.dom.minidom.Node):
>         n.unlink()
>     else:
>         xml.dom.ext.ReleaseNode(n)
> 
> try:
>     from Ft.Lib import pDomlette
>     def ReleaseNode(n):
>         if isinstance(n, pDomlette.Node):
>             pDomlette.ReleaseNode(n)
>         else:
>             _releasenode(n)
>     _XsltElementBase = pDomlette.Element
> except ImportError:
>     ReleaseNode = _releasenode
>     from minisupport import _XsltElementBase

Wouldn't it be better to make up a Reader class for minidom which
implements a releaseNode method similar to what you have above?  The
idea behind the reader architecture is to manage such things.

There might be some places in 4XSLT that don't properly call releaseNode
on the reader instance itself, but I'd rather fix them to do so.

What's "minisupport" and "_XsltElementBase"?


> This code knows how to release minidom, 4DOM, and pDomlette nodes, and
> supports installations without 4Suite (i.e. without pDomlette). I've
> put this into xslt/__init__.py, so that all callers of
> Ft.Lib.pDomlette.ReleaseNode now need to call xml.xslt.ReleaseNode.
> If desired, I could produce a patch against the public Ft CVS.
> 
> As a slightly independent question, such a function also ought to
> support DOM implementations not known to it; I'm thinking in
> particular of the Zope DOMs. I'd like to hear proposals on how such an
> interface should work; I see three options:
> 
> a) it is an operation on the document node (or any node), as in minidom.
> b) it is an operation on the DOM implementation (almost as in 4Suite;
>    you'd need to navigate from the node to the implementation, then
>    you'd need a well-known operation on the implementation)
> c) the code assumes that no release activity is necessary for unknown
>    DOMs, effectively believing in reference counting, garbage collection,
>    acquisition, and other black art.

Maybe we need a general Reader class for unknown DOM classes.  This
would require the unification of DOM factories we were discusing a few
months ago, but the releaseNode method could just be a NOP, i.e. your
(c) option.

> Any comments appreciated, in particular
> 1. from the Ft maintainers on introducing xml.xslt.ReleaseNode, and
> 2. from authors of other DOMs on a general memory management API for
>    Python DOM.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python