[XML-SIG] Future plans

[uche.ogbuji@fourthought.com]

>      * I propose dropping the wstrop and xmlarch code from the CVS
>        tree: wstrop because Python 1.6 will have built-in Unicode
>        support of some strip, and xmlarch because architectual forms
>        are fairly rarely used, and don't need to be in the core.

Agreed, although we might want to wait until Python 1.6 is out before dropping 
the former.

>      * What about namespace support in SAX -- what's the status of SAX2?

Lars published a SAX2 module that pretty much covers the ground of the current 
status.  I've been cajoling the folks on XML-DEV to finish the SAX2 spec, and 
things are coming about slowly.  4DOM comes with a pretty complete SAX2 -> DOM 
reader, which is used by 4XSLT.

>      * The DOM needs more work.  I've fixed the braindamaged __getattr__
>        that was terribly slow; building a DOM tree of "The Winter's
>        Tale" now takes around 25 seconds, not 80.  (4DOM takes around
>        12 seconds for the same job.)  The accessor methods
>        need to be renamed to match the Python CORBA mapping, and the
>        code needs to be brought up to DOM Level 2, which will add
>        namespace support.

DOM Level 2 also updates Document factories so that most nodes can be created 
in a standard way.  The way they use DocumentType for the purpose is a bit 
dodgy, IMHO, but it's there.  DOM Level 2 also for practical reasons occupies 
an odd position between straight XML 1.0 behavior and XML with Namespaces 
behavior, but it does the job of adding namespace support.

>        I'm still wondering if it's worth maintaining a second DOM
>        implementation in parallel with 4DOM.  4DOM 0.9.0 already
>        implements Core Level 2 according to Uche's recent
>        announcement.  

I used to say that PyDOM and 4DOM addressed different users, but over time, 
changes to 4DOM have made this less clear.  4DOM is now far more pythonic and 
light-weight than when it started out.

>        I worry about 4DOM requiring you to do ReleaseNode() in order
>        to break cycles, envisioning tricky bugs where you forget to 
>        release a node and end up leaking memory, or where you release
>        too soon.  Perhaps this is just paranoia; for most common
>        applications, maybe you just create a DOM tree, rearrange it,
>        write it out, and then release the whole tree -- no tricky
>        business about keeping some nodes and releasing others.
>        Any 4DOM users/developers want to comment on this?

Yes, the ReleaseNode could be the source of memory leaks.  We experimented 
with a few automatic methods, and were very unsatisfied with all of them.  We 
haven't ever had any difficulty hunting down memory leaks when they occurred 
because of a missing "ReleaseNode", even without plumbo or cyclops.  We have 
installed 4DOM into some rather long-running systems, and some at rather large 
scale.


-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org