xml based extensions using libxml

As people may be aware, the new dom and xslt extensions are already
underway. We have run into situations that are going to need to be worked
out to insure interoperability amongst the different extensions using
libxml.

One concern is the use of the libxml globals. Changing these changes them
across all the extensions using libxml when running together. We cant
anticipate the compiling of libxml to use threads so should work around this
within the extensions itself. This most likely will mean using lower level
libxml calls where it doesn't require the use of a global but allows you to
set the value directly.

There should be a common api developed as well so that the extensions can
interoperate. Chregu has already started on it as he has portions of the new
xslt extension work with the new dom extension. This should be hashed out
for all extensions that need or should be able to work together.

Register/DeRegister callback functions. I am hoping to be able to employ
deregister callbacks within the dom extension, not sure if there are any
others that need it. By using this, the dom extension will be able to be
sped up by at a minimum of 2x. The problem again is that it is global. A few
ideas have been tossed around to allow this functionality, but they do have
draw backs.

Use of a common function in the common api which would perform the
functionality based on where (which extension) the node was created from.
This could be achieved via a common struct for all extensions that the
_private for nodes points to.

Drawbacks:
    extensions not needing callback functionality would still run through
the common function each time, though not doing anything. This would slow
their performance down a bit.

    possibility that the _private may not be able to conform to the common
structure. It has been noted that libxslt itself uses the _private, but this
needs to be researched further.

    every extension which uses some of libxml's global features must conform
to the standard api. If you look at the current xml extension, this is an
isolated extension so does not and is not affected by outside extensions.

    in order to employ the callbacks, libxml 2.5.x is required.

Without some sort of agreement from everyone, we are going to have
extensions breaking other extensions. It will need to be documented as well.
Custom extensions would have to conform to the standards if they were to be
run along with any others so the "rules" are going to have to be available.
Probably not a big issue, but a possibility.

These are just some of the initial things I wanted to bring up. There are
probably more things that will need to be worked through, but after looking
at all the xml stuff this week it is getting hard to think clearly right
now.

I would also be a good idea to get a list of whomever is working on any
extensions employing libxml so that things can get coordinated a bit. I know
there are at a minimum one or two others working on the above.

Comments/Suggestions/Ideas?

Rob