xml based extensions using libxml

From: Date: Thu, 15 May 2003 15:59:27 +0000
Subject: xml based extensions using libxml
References: 1  Groups: php.xml.dev 
Request: Send a blank email to php-xml-dev+get-112@lists.php.net to get a copy of this message
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

« previous php.xml.dev (#112) next »