First off trimming down means. removing documentation. removing install help. NOT removing any code at all!
Why do you feel that bundling is such a burdon and how does it requires more testing. If libxml release a new release and it is decited to upgrade then simply upgrade. I don't understand why you think its such a burdon. It looks like they are releasing a version once a month. I don't really think a hour of a developers time a month is much of a burdon. Besides the fact that i don't think we need to upgrade everytime libxml upgrades. If we bundle the newest one right now php and all of it's xmlbased extensions will work fine. if a new one gets released... so.... if we (php group) feels that its worth the upgrade then go we do it. Otherwise if an end users feels it is in his best intrest to get the newest version the by all means he can. Im not saying that we need to force a version on them but give them a hand if they don't have any installed. But one thing that I didn't think of that andy pointed out is. The ability for php/zend's core or extensions to use xml. (ie config files for new extensions that are separate from php.ini) Xml is so widley used everywhere. You want proof that xml is widly used??? Are you serious? What kinda comapany do you work for? We pretty much use xml and xml based techonlogies in 90% of our projects. And talk about objective points? Your points don't seem more objective than mine. - Brad --- Dan Kalowsky <[EMAIL PROTECTED]> wrote: > Let's please try to keep the points objective. > > > 1) don't include at all > > pros: > > No need to worry about auto install or filesize. > > cons: > > Forces people to install themselves. > > Is this really a valid con? This is the standard method of adding > functionality to ANY programming language. It's not forcing anyone to do > anything. If the end user decides that they would like to have XML > capability, they will take the steps required to install such services. > As of this moment that includes downloading and installing the libxml > services. > > > 2) trim down libxml and put in cvs > > pros: > > Build outta the box. Makes php to build without having to download extra > > libaries for highly used extension like domxml. Since domxml requires a > newer > > version of libxml than most people have it requires them to go an install > it > > before buiding php. > > Unless you have hard numbers, I'd really appriciate you not stating domxml > is a highly used extension. Stating opinion as fact isn't going to help > here. > > > cons: > > People feel that maintaing this would be too much of a hassle. > > Conserns about file size of the php package. > > Please keep these points to an objective point, and not a rhetoric with > emotion. > > Con(s): > - Requires maintaining code integrity across new versions of libxml > - libxml is a moving target > - Will require double the effort to provide a 0% increase in output. > - Trimmed libxml is not a full libxml, leading to possible end user > confusion. > - Adds a new point requiring multi-platform release testing. > > > 3) figure out some method to auto download config/install > > pros: > > No extra filesize for php source. No matinance for php developers. > > This point would be more valid for the "requires minimal interaction with > PHP developers" (i.e. hosted site changes location, path, or filename). > > > cons: > > Someone needs to build this (semi complex). > > Reliant on other servers being up/ asseable from clients machines (ie > have > > internet connection from the machinge its being installed from) > > Is this last really a con? It's the same problem across the debian > apt-get, the BSD ports collection, and even for getting PHP itself. > Which I believe is the more common way for people building PHP than > actual tarballs. Although this is only conjecture with no real proof, so > take that with a grain of salt. But these methods also check local > library versions and will automatically get/update the library if > necessary on a per flavor basis. > > > 4) Try and automate the sliming down of libxml and incorp it in the make > dist. > > pros: > > Still have outta the box but it doesn't live in our cvs. > > cons: > > Someone needs to build this (relitivly simple). > > Still have the filesize issue. > > Please do not dismiss the trying to hit a moving target as simplisitic. > It's not. Having worked with moving targets in the past I can assure you, > it is not a fun task. It gets exhausting very quickly. > > Con(s): > - No way to automatically ensure new functionality validity > - Will still require developer intervention (albiet less) > - Will require multiple OS testing > - Will not be valid if libxml is re-written/re-architectured > - No way to tell if automated merges have selected the proper option > (i.e. bug fix in PHP version and not in official distro). > > But you did forget at least one other option: > > 5) Provide a better form of documentation for the end users describing > versions with which to use any/all extenions. > > Pro(s): > - Doesn't require bundling of external code > - Doesn't increase distribution footprint > - Doesn't require double the developer time/effort > - Keeps actively maintained libraries away from PHP developers concern > - Benefits the entire PHP community rather than a single branch > - Keeps the end user informed > - Can potentially cut down on submitted bugs by keeping user libraries > upto date with the library versions developers/testers are using. > > Cons: > - Requires making information prominent on the web page and within > releases > - Requires PHP's extension developers to keep upto date information > local/specific to PHP only > - Requires being translated to all languages PHP manual is available in > > > Do we vote? > > Do we have all the options listed, along with their pro's and con's yet? > > >---------------------------------------------------------------< > 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] > __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
