> Months from now I honistly can't say what i'll be doing. For all I know i > could get hit by a car. I don't plan on ditching my contributions anytime soon. > But I don't see my contributions a factor in deciding if we should bundle > libxml.
Exactly the unspoken point. While I'm not saying you will be ending your contributions anytime soon, at the point if/when you do there is no assurance of continued updating. As Andi pointed out, even with this "assurance" from the MySQL team, it doesn't always happen. > I don't see bad merges a problem here. It's not like I would be applying > patches or getting the latest and greates from libxml's cvs. Peridocially > someone would just need to update the source files from the 'newest' release. Prune'ing the source from 2MB to 800K is a rather drastic size decrease. That will be where any maintaince and what not will be required. It would not be just update to the 'newest' release. It would also require ensuring that these are still the only files necessary, the build still works, and so on. Possibly minor work, but one which will still take time from someone which really doesn't need to be expended. > I don't know how much developement other people do but use xml/xml > techiologies on a daily basis. I see this is the trend of many developers but I > obvisouly cant speak for them. I don't disagree with XML becoming a more essential technology for development. But because it is becoming a more essential technology I don't see a reason to bundle a PHP specific version of a commonly used library. Especially while it is still actively maintained, and more core services and functionalities are beginning to require it. > The ability to build outta the box is also what many system admins what to > see, maybe not the hacker ones but the ones who "just get the job done". I also > know alot of managers that will pay for software just cuase it runs outta the > box. No needing to depend on other software is installed. I wish this point would be dropped, if only for a basic problem with this arguement. PHP cannot (nor should it in my opinion) be a "build outta the box" process. Why? Because it would require bundling a large number of external libraries. PHP will always depend upon external libraries. That is how programming languages work, which is what PHP has/is become(ing). What, for example, makes libxml any more special than say iODBC? iODBC runs on many (if not all) platforms. It provides a universal ODBC access to countless databases. It supports ODBC v3.7 compliant calls, thus we could update the PHP ODBC routines from 2.0 to 3.7. ODBC was/is considered an essential technology for database access as well. These points are all similiar to those being made for including libxml. The main point of this being, where does the PHP environment draw the line and say "No this should be" or "Not this shouldn't be" bundled? If you want an "out of the box" solution, this line will never be drawn, and we should just start bundling everything now. If you say only specific libraries should be who gets to decide, and what is the criteria for inclusion? It is far easier and a more sane option to not even begin that path, or to continue further down that path. > Ok we bundle gd... gd is very usefull for many sites/applications but common > don't you feel that xml is a little bit more important than gd? It's not a point of if gd is more important than XML. gd is not, nor has it been for a long time, actively maintained. PHP's bug database was beginning to fill up with bug reports about gd not working. Patches were being done and maintained on various sites to fix bugs internal to gd itself. Yet there were no official releases to incorporate them. While I don't completely agree with the bundling of gd either, I also didn't have any better solution to suggest. This hasn't been the case with the libxml. Any bugs and patches submited to the development team are incorporated (provided their validity) into an official release. There are no external sites with patches (that I know of offhand) to fix a specific function within the libxml library. > Seriously we bundle expat why wouldn't we bundle libxml. It's way more usefull > than expat. I don't agree with the fact that expat is bundled either. But that is something I wasn't around to argue, or if I was I somehow missed it entirely. As of right now, that isn't likely to change anytime in the future either. I'm normally extremely quiet on the list unless I have questions or see something I disagree with. Enabling by default and bundling external code are two things I believe should just be avoided. >---------------------------------------------------------------< Dan Kalowsky "The record shows, I took the blows. http://www.deadmime.org/~dank And did it my way." [EMAIL PROTECTED] - "My Way", Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
