Re: [PHP-DEV] libxml bundling
On 3 Jun 2002, Stig S. Bakken wrote: [...] Such sysadmins have already learnt the usage of --without-xxx options. Sure they do, but it's still annoying for them to see new things enabled-by-default in every new release. Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Fri, 31 May 2002, brad lafountain wrote: [...] 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. It requires testing because it is yet another piece of code that needs to be nice to the configure system, and has to play nice with other libraries that might have linked in libxml. 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. Of course not, but the libxml library has a lot of important bug fixes [1] too with every release, and I'd rather have a version with less bugs than the PHP bundled one. [1] http://www.xmlsoft.org/news.html 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. I indeed like to see some proof that it is used so widely. You state that XML is widely used, but I really think that this is only true for a small part of the people who work with PHP. This does not mean I don't see value in XML, it's certainly usefull... but that doesn't warrant bundling it and enforcing it for users who don't want or need it. Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
I indeed like to see some proof that it is used so widely. You state that XML is widely used, but I really think that this is only true for a small part of the people who work with PHP. This does not mean I don't see value in XML, it's certainly usefull... but that doesn't warrant bundling it and enforcing it for users who don't want or need it. xml is already bundled. We're idea was more about moving from xpat to libxml2. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, Jun 01, 2002 at 04:21:33PM -0400, Dan Kalowsky wrote:
When I state that things shouldn't be enabled by default, it is not
towards making it harder for beginners. I would much rather see PHP
using
something like:
./configure --basic
or
./configure --standard
or some variation along that theme.
On Sun, Jun 02, 2002 at 12:25:17AM +0300, Zeev Suraski wrote:
Why not have a --bare (or equivalent) switch of that kind, to disable
literally EVERYTHING that's not mandatory? I believe the issue is that for
instead of modifying ./configure to allow grouping a set of --with{out}
--{en|dis}able into one option (--basic, --bare, ...) i propose setting
up brothers of ./config.nice like
./config.bare
./config.basic
./config.standard
./config.everything
it'd be obvious _what_ these scripts enable, and you could easily use
them as a template to modify these things to get everything minus odbc
or bare + pdf.
-lukas
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Andrei solved it. It is because socket_select() mangles the passed
arrays
so when you re-enter the call with the mangled $read array you are now
only checking the sockets that happened to trigger the first time
through.
It means you actually have to do:
$read = array($sock1,$sock2);
$copy = $read;
while($num=socket_select($copy, $write=NULL, $except=NULL, NULL))
{
for($i=0; $i$num; $i++) {
usleep(500);
$msg = socket_read($copy[$i],1024);
echo [$i] .strlen($msg).\n;
}
$copy = $read;
}
So you save the original array of sockets to pass back in. This is
why
the C API has FD_ISSET() to check the result of a select(). I really
don't like this current behaviour of socket_select(). It will confuse
the
hell out of anybody coming at this from a C background.
Yeah, it's a little confusing for C-Programmers, but I think it is OK to
do it in this way. The manual extra points a big note, that naming is
like in C, but the behaviour can be completely different.
Reverting the removing of the fd_* functions would actually more confuse
the users (again) then leaving a note in the manual ...
Just my 0,02$
Greetings,
Marcel Beerta
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sun, 2 Jun 2002, Lukas Schroeder wrote:
instead of modifying ./configure to allow grouping a set of --with{out}
--{en|dis}able into one option (--basic, --bare, ...) i propose setting
up brothers of ./config.nice like
./config.bare
./config.basic
./config.standard
./config.everything
This is, in the end, the sort of ultimate I idea I had. A system of
pre-defined flavors for configure to use. The only problem I keep
running into: the need for library paths.
---
Dan KalowskyThe record shows, I took the blows.
http://www.deadmime.org/~dankAnd 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
Re: [PHP-DEV] libxml bundling
On Sat, 2002-06-01 at 02:08, [EMAIL PROTECTED] wrote: On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. XML is a basic building block of the web these days. I really can't say that about ODBC. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. Such sysadmins have already learnt the usage of --without-xxx options. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, 1 Jun 2002, Zeev Suraski wrote: Guys, Unless somebody strongly objects, I suggest we drop the discussion about how horrible it would be to import libxml2 into our CVS. I believe it's well established that it's a Bad Thing to do, there's no point hashing it. yep :) I believe the question on the table is whether libxml2 is important enough from an end-user's point of view to be built into PHP. If we decide that the answer to that is positive, then there's a fairly easy way of doing that. My personal opinion is that XML today is as basic and important as ASCII, so bundling libxml makes good sense. I believe that bundling at the makedist level makes the most sense, because: (a) Synchronization is trivial (b) We get to choose what libxml we use, so our libxml-dependent code doesn't have to support the zillion different libxml's out there (the moving target argument, in my opinion, is a good reason for us to bundle a stable version of libxml rather than support all versions out there) I do not agree with that. libxml is a moving target feature wise, but they really try to keep the api stable (they do not succeed always :) ). I don't see any sense not supporting the latest available libxml2 version (they bugfix and speedimprove it constantly), but just some version, we think is stable (libxml2 was never a problem recently with stability). And at the moment, we do not support zillions of libxmls, but only versions greater than 2.4.14 (which had unfortunaly a little api-change, so we can't support lower versions anymore) We need to address the symbol clash issue, and that's about it. Does this mean, we are not able to link it to an already existing external library anymore and we always include it into the executable (adding 1.5 MB to the exec and not sharing it with other programs), or do i really miss something (hey, it's early...)... Furthermore, if we support linking to an external libxml2.so/.dll, we have to support new versions anyway ... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
At 12:45 PM 6/1/2002, Christian Stocker wrote: I believe that bundling at the makedist level makes the most sense, because: (a) Synchronization is trivial (b) We get to choose what libxml we use, so our libxml-dependent code doesn't have to support the zillion different libxml's out there (the moving target argument, in my opinion, is a good reason for us to bundle a stable version of libxml rather than support all versions out there) I do not agree with that. libxml is a moving target feature wise, but they really try to keep the api stable (they do not succeed always :) ). Feature-wise in a way that the wrapper module code won't have to change in order to take advantage of? I don't see any sense not supporting the latest available libxml2 version (they bugfix and speedimprove it constantly), but just some version, we think is stable (libxml2 was never a problem recently with stability). And at the moment, we do not support zillions of libxmls, but only versions greater than 2.4.14 (which had unfortunaly a little api-change, so we can't support lower versions anymore) Well, I'm not sure how this translates, but there's a saying that if you try to get it all, you end up getting nothing. One of the two big issues people had with libxml's bundling is the fact that it's a moving target, so it would be a headache to bundle. I'm definitely not in a position to say whether that is true or not, but I know that taking a certain version and sticking to it can't be much of a problem. If we end up seeing that taking the latest version at each release (we release every few months now, not every other week!) is not difficult either, there'll be no reason not to do it. The other problem is the download size, and I don't believe that is a real issue, considering the importance of this library. We need to address the symbol clash issue, and that's about it. Does this mean, we are not able to link it to an already existing external library anymore and we always include it into the executable (adding 1.5 MB to the exec and not sharing it with other programs), or do i really miss something (hey, it's early...)... Furthermore, if we support linking to an external libxml2.so/.dll, we have to support new versions anyway ... I guess it depends to the answer of my first question - whether new features will be transparently available to users, even without changes to the wrapping PHP module. If that's the case, we probably should think of a way to support the local library, probably in the same way we handle MySQL. If not - I see no problem in always using the bundled library, regardless of what's already installed - on the contrary, I see a fairly big advantage. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, 1 Jun 2002, Zeev Suraski wrote: At 12:45 PM 6/1/2002, Christian Stocker wrote: I believe that bundling at the makedist level makes the most sense, because: (a) Synchronization is trivial (b) We get to choose what libxml we use, so our libxml-dependent code doesn't have to support the zillion different libxml's out there (the moving target argument, in my opinion, is a good reason for us to bundle a stable version of libxml rather than support all versions out there) I do not agree with that. libxml is a moving target feature wise, but they really try to keep the api stable (they do not succeed always :) ). Feature-wise in a way that the wrapper module code won't have to change in order to take advantage of? yes, bugfixes and speed improvements. We don't have to change the wrapper module to take advantage of speed improvements in libxml2 or for example bug fixes in the xpath implementation (2 issues currently discussed at the libxml mailinglist) But also feature-wise in adding new features (for example xml-schema support). Though, the php-module does not take advantage of this without adding new functions ... I guess it depends to the answer of my first question - whether new features will be transparently available to users, even without changes to the wrapping PHP module. If that's the case, we probably should think of a way to support the local library, probably in the same way we handle MySQL. If (!!) we bundle, then this is the only way to go IMHO If not - I see no problem in always using the bundled library, regardless of what's already installed - on the contrary, I see a fairly big advantage. I see really no advantage in this approach (more memory needed for example, maybe symbol clashes and all other reasons from sync-hell i mentioned in my previous mails ) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
At 02:23 PM 6/1/2002, Christian Stocker wrote: If not - I see no problem in always using the bundled library, regardless of what's already installed - on the contrary, I see a fairly big advantage. I see really no advantage in this approach (more memory needed for example, maybe symbol clashes and all other reasons from sync-hell i mentioned in my previous mails ) I think that the MySQL example is a perfect illustration of why it works, and works well. Sure, there were the few who experienced problems because they also had mod_perl or mod_auth_mysql, but then there was the vast majority, for whom it just plain worked, and worked well. The advantage here is the same advantage there - it would work out of the box, without any hassle. The consumes-more-memory issue is really a non-issue, given the memory models we're dealing with; The symbol-clashes issue should be checked, we may be able to fix it through versioning; and I see this is as the perfect solution to the synchronization hell, rather than something that makes it worse. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Zeev: I believe there's at least one company that effectively proved that the opposite is true, there are probably many others. I don't see a problem in having core technologies enabled by default. Purists can turn them off, but there are a hell of a lot more average users than there are purists. This is the crux of the issue, and in my not-so-humble opinion it isn't really understood by the group of developers I affectionately call the #php.bugs mob. It seems to me that PHP is increasingly being modeled for a largely imaginary audience of purists. I say imaginary because I just can't see how droves of purists would've become involved with PHP in the first place. As Rasmus has repeatedly pointed out on this list, PHP was sold to its users by Hello, ? echo $name ?, and the ease of getting to that point. Each additional hoop they have to jump through to get there, be it installing libraries or tinkering with php.ini settings, will make them less interested, and, importantly, less excited about PHP. Everyone should keep that in mind when plotting the next step to purity. It's very easy to underestimate the consequences of, for example, disabling the short tags, making everything case sensitive or eliminating register_globals for good. The benefit might be language correctness, but the downside is much more quantifiable: frustrated users. At its core, this is also what bundling libxml is about. I'm not going to jump to conclusions for you, but please keep in mind the extreme importance of continued ease of use when deciding such issues. Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Marko Karppinen wrote: It seems to me that PHP is increasingly being modeled for a largely imaginary audience of purists. I say imaginary because I just can't see how droves of purists would've become involved with PHP in the first place. I don't want to see changes (like those you mention later in your posting) in PHP to attract new users, but more to bind people that already use PHP, but are about to outgrow it. If you (and others) want PHP to stay at the BASIC for the Web level forever - fine, but spell it out clearly. Otherwise people who are waiting for PHP to evolve beyond that will become more and more frustrated. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
At 05:05 PM 6/1/2002, Sebastian Bergmann wrote: Marko Karppinen wrote: It seems to me that PHP is increasingly being modeled for a largely imaginary audience of purists. I say imaginary because I just can't see how droves of purists would've become involved with PHP in the first place. I don't want to see changes (like those you mention later in your posting) in PHP to attract new users, but more to bind people that already use PHP, but are about to outgrow it. If you (and others) want PHP to stay at the BASIC for the Web level forever - fine, but spell it out clearly. Otherwise people who are waiting for PHP to evolve beyond that will become more and more frustrated. That's a big twist of this view. If evolving means that PHP will no longer address the beginners' market, then yes, I don't think any of the original authors want it to 'evolve'. That is not, however, what we're talking about. PHP can, has, and will address multiple userbases, beginner, intermediate and advanced. We should go on doing our best to improve it in all fronts, because except for psychological problems, one doesn't necessarily affect the other. It may come to you as a surprise, but there are lots of advanced users who don't enjoy downloading and building, and prefer to see stuff working out of the box. There are the ones who admire downloading, configuring and building each of their apps, and then there's the rest of the world who gets the same job done in a fragment of the time by downloading an RPM or an InstallShield archive. It's a free world, and we should not try to educate it. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Zeev Suraski wrote: It may come to you as a surprise, but there are lots of advanced users who don't enjoy downloading and building, and prefer to see stuff working out of the box. I was not adressing the issue this thread is about (bundling 3rd party libraries), but rather Marko Karppinen wrote: disabling the short tags, making everything case sensitive or eliminating register_globals for good. True, PHP will make OOP development easier and richer with the advent of the Zend Engine 2. But there's still a long way to go after that to reach a state I'd [*] like to see. -- * Maybe that's a bit egoistic. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
* Sebastian Bergmann wrote: I don't want to see changes (like those you mention later in your posting) in PHP to attract new users, but more to bind people that already use PHP, but are about to outgrow it. If you (and others) want PHP to stay at the BASIC for the Web level forever - fine, but spell it out clearly. Otherwise people who are waiting for PHP to evolve beyond that will become more and more frustrated. +1. The ease of PHP - one of its biggest advantages is also one of its biggest disadvantages. IMHO. Björn. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, 1 Jun 2002, Zeev Suraski wrote: I believe there's at least one company that effectively proved that the opposite is true, there are probably many others. I don't see a problem in having core technologies enabled by default. Purists can turn them off, but there are a hell of a lot more average users than there are purists. I don't have the time right now to fully organize my thoughts on this and many of the other emails so you'll have to wait for my response (I know I know). When I state that things shouldn't be enabled by default, it is not towards making it harder for beginners. I would much rather see PHP using something like: ./configure --basic or ./configure --standard or some variation along that theme. Where whatever options are considered by the PHP development community as essential can be enabled. A ./configure should really just build a basic vanilla PHP in my mind. But this concept also goes against 6+ years of configure scripts, and I realize it's an uphill battle. I know it annoyed me to no end that MySQL was being built automatically when I first started using PHP. Or maybe the opposite of this should be allowed. A --disable-standard flag that will turn off all the options PHP developers believe are essential, but can then be overloaded with other options. I have no idea if it is technically feasible, but it's an eventual direction I would rather see. Finding what is enabled by default right now is too difficult, and we just keep plugging in more. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd 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
Re: [PHP-DEV] libxml bundling
Why not have a --bare (or equivalent) switch of that kind, to disable literally EVERYTHING that's not mandatory? I believe the issue is that for every 'purist' that cares about bloat, it's safe to say there's more than one user (*) that prefers stuff to 'just work', and not mess with additional downloads, install documents and builds. Zeev (*) That's a probably a *BIG* understatement. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
At 13:12 31/05/2002 -0700, brad lafountain wrote: Ok, I think we are split in two about what to do here. Ill try and list the different ideas that have been proposed. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. I just want to mention one of the more important reasons why I think it's a good idea to include it in the tree. It means that PHP itself and its extensions can rely on having the C API present and can add XML functionality in various places. Andi 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. cons: People feel that maintaing this would be too much of a hassle. Conserns about file size of the php package. 3) figure out some method to auto download config/install pros: No extra filesize for php source. No matinance for php developers. 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) 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. Do we vote? - Brad __ 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Andi Gutmans wrote: At 13:12 31/05/2002 -0700, brad lafountain wrote: Ok, I think we are split in two about what to do here. Ill try and list the different ideas that have been proposed. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. I just want to mention one of the more important reasons why I think it's a good idea to include it in the tree. It means that PHP itself and its extensions can rely on having the C API present and can add XML functionality in various places. Andi I wish it became a default module, too. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
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 KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd 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
Re: [PHP-DEV] libxml bundling
On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: I just want to mention one of the more important reasons why I think it's a good idea to include it in the tree. It means that PHP itself and its extensions can rely on having the C API present and can add XML functionality in various places. Andi I wish it became a default module, too. And I will argue that point as well. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd 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
Re: [PHP-DEV] libxml bundling
Just an overall reply to a point you're making - yes, making the user download and build something if he wants to use XML is really a con, in my opinion. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
At 11:19 PM 5/31/2002, Andi Gutmans wrote: At 13:12 31/05/2002 -0700, brad lafountain wrote: Ok, I think we are split in two about what to do here. Ill try and list the different ideas that have been proposed. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. I just want to mention one of the more important reasons why I think it's a good idea to include it in the tree. It means that PHP itself and its extensions can rely on having the C API present and can add XML functionality in various places. It doesn't mean that it has to be in the CVS tree, by the way - if we decide that checking out libxml (or untarring a certain version) is a standard part of getting a PHP source tree ready for development. From what I hear, putting libxml in our CVS is really a bad thing to do, because it's a very active project. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
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
Re: [PHP-DEV] libxml bundling
And talk about objective points? Your points don't seem more objective than mine. Would you localize the symbols in it? What happens if someone loads up another DSO into Apache that also uses libxml? We currently have that headache with expat where someone who uses Apache + PHP + mod_perl have 3 projects that all bundled their own expat and it is quite a hassle to negotiate. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Hi again 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. And then, someone thinks he needs a feature in libxml2, which was not approved by the libxml2 folks, merges that into the php-libxml2 source tree and you are in trouble for the next upgrade... (just an example, how you could end up very quickly in upgrade hell, doesn't have to happen, but my observation of the php-developement doesn't outrule that, either :) ) 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. öööhm. I don't know, how many people here are a little bit familiar with the implementation of libxml2 in php, but before talking about integration of that stuff in a lot of places in php/zend, we should first find a way to make it really (or almost) memory leak free. This is now a little bit better than a few weeks ago, but it's still far from perfect. I won't go into details here, but Lukas Schroeder made some suggestions, how to improve it, but we didn't came up till now with the perfect solution. The main problem lies in the fact, that libxml2 can free nodes without notifying anyone and especially not the zval containers and here come the problems with freeing memory and some segfaults Furthermore, I still think, Sterlings idea of an unified XML-extension would be a good idea (sebastian posted that link some days ago), but it would be a pretty big task. For me it's rather painfull, to have to use different extensions for SAX, DOM and XSLT (ok, the later two can be used with the same extension in the meantime), which can't communicate with each other in a reasonable way. Just my 2 cents before everyone thinks libxml2/domxml is the perfect solutions for all xml-tasks in php (it will be some day hopefully, but it isn't right now) 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. no, i think, he wants proof, that domxml/libxml2 is widely used everywhere there are other ways to use xml than with domxml and since domxml is still (for good reasons) marked experimental, a lot of people avoid to use it. And for the record: I'm still against bundling. Though better documentation, where to download libxml2 and how to install it seperately, even an automatic thingie for that, would certainly help some people. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
[EMAIL PROTECTED] wrote: On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. I see xml and unicode as critical technologies for PHP in it's role as a web based scripting language, as critical as html itself. If people cannot seperate that from the issue of embeding a bit more code in PHP distributions, and recognize that xml is as critical to the future of PHP as the web itself, well, there's no convincing. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Guys, Unless somebody strongly objects, I suggest we drop the discussion about how horrible it would be to import libxml2 into our CVS. I believe it's well established that it's a Bad Thing to do, there's no point hashing it. I believe the question on the table is whether libxml2 is important enough from an end-user's point of view to be built into PHP. If we decide that the answer to that is positive, then there's a fairly easy way of doing that. My personal opinion is that XML today is as basic and important as ASCII, so bundling libxml makes good sense. I believe that bundling at the makedist level makes the most sense, because: (a) Synchronization is trivial (b) We get to choose what libxml we use, so our libxml-dependent code doesn't have to support the zillion different libxml's out there (the moving target argument, in my opinion, is a good reason for us to bundle a stable version of libxml rather than support all versions out there) We need to address the symbol clash issue, and that's about it. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
Did you conduct a survey about that? I believe there's at least one company that effectively proved that the opposite is true, there are probably many others. I don't see a problem in having core technologies enabled by default. Purists can turn them off, but there are a hell of a lot more average users than there are purists. That said, XML is the ASCII of this age, which makes it more important to enable than any of the other modules that you mentioned. Zeev At 03:08 AM 6/1/2002, [EMAIL PROTECTED] wrote: On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
