Re: cvs: php4 /ext/qtdom qtdom.c qtdom.h

At 06:28 PM 11/16/2000 +0000, Bård Farstad wrote:

To me this is a little bit like saying we should only support one SQL database. Or one type of dbm. I don't think we should be making the call and forcing someone to pick one xml library over another. If enough people out there use qtdom I think we should support it. -Rasmus I agree. And the fact that the GNOME DOM parser does not handle XML files with e.g. cdata fields or the XML files that openoffice.org generates makes the qtdom parser neccesary. ( Atleast I could not get them to work ) We could always fix the GNOME parser, but when we have a working XML parser and an implementation of an PHP extension for it we should let people use it. We have already developed alot of software which use the qtdom extension in PHP. All of this is going to be released under GPL so from a community standpoint people would get the software quicker from us :)

First off let me just say that I mean no dis-respect to the author(s) of this extension, I truly do respect your work and your generosity for developing and contributing this extension. In response to you needing the QtDom extension for your application, you can distribute that extension with your software, it really only requires the use to enter in three or more commands and they've got the Qtdom parser working (./configure, make, make install). I just think its not a good idea to distribute to extensions that provide the same functionality, are you sure that the problem lies in libxml itself, not in the extension? Perhaps its an easy fix in the dom-xml extension to PHP? Perhaps its an easy fix in libxml itself, perhaps you might be doing something wrong in the setup, and perhaps, your right, libxml currently does not support it, perhaps the next release of libxml will, then what? You can't remove the QtDOM extension because code relies on it, and it really then provides absolutely no extra functionality. That's why I think QtDom is better suited as an external extension. A new extension should not be added to PHP simply because it fixes a single bug in a current working extension, at least not until every other option has been exhausted. Especially since that bug may be fixed, and then your stuck with an extension that can't be removed for fear of backwards compatibility and really isn't worth furthering because you've got another more developed extension in the cvs repository which provides the same functionality... It also doesn't make sense as far as user-space considerations goes, you mean PHP is distributing to extensions which do exactly the same thing, the only difference is that one of them doesn't have a bug related to cdata fields (but is less robust)? To me that doesn't make sense, fix domxml, don't create a new extension that seems destined to be obsolete the second a bug gets fixed. If QtDOM offered some signifigant new functionality, a much faster parser, or something else I could perhaps see the rationale in adding it, but as it is, I think it might be better to distribute QtDOM separately from PHP. -Sterling