Rasmus Lerdorf wrote:
>>Look at it from their point of view. Say, as a customer, you want to use
>>library X. The ISP looks around and eventually find it lives on a personal
>>site in Greece or Hungary. Not very confidence inspiring. The ftp on this
>>site is broken, so they email the author and wait a couple of days before
>>they can download. The documentation may be thin or non-existent. There is
>>no guarantee that this library has been tested to work with the release of
>>PHP they are running, or that it will be maintained in the future. To
>>install it they have to rebuild their PHP setup. There is, so far as I am
>>aware, no regression test they can run to be sure they have not broken their
>>installation for the other 400 customers using the server. Then they have to
>>take the server down to install the new build. Is it any wonder that they
>>just say "no"?
>But the situation is exactly the same for Perl or Python or even Java for
>that matter. None of these environments ship all the 3rd party libaries
>that they connect to. And asking us to maintain 200+ libraries is
>>Now compare this with Perl or Java, where they simply plug in the new
>>functionality without any significant risk of breaking their server setup.
>How so? If you want Perl DBD-DBI for Oracle, you need to first go find
>the Oracle client libs. The same is true for most other Perl addons.
>Chances are the ISPs are just slightly more familiar with the bits they
>need to go find for Perl. The situation is actually quite a bit messier
>for Perl as there are currently over 100 time handling classes in CPAN,
>for example. PHP has a single standard one that ships with PHP.
perl -MCPAN -e shell
Actually I forget if that's an actual package or not. :)
But that's *generally* as easy as it is for many Perl packages I need.
(I've hit a few snags,
but not as many as in PHP). The DBD::MySQL stuff went out and grabbed
MySQL libraries and compiled them on my system. PHP ships with MySQL
but for other packages where I have to compile stuff (which *rarely*
works as directed,
because, no matter WHAT version of Linux I'm using, it's not a "real"
distro) this step
is always a huge pain.
>>1) Propose a library documentation standard based, say, on CPAN and get it
>>adopted by the community
>Already done in PEAR
>>2) Set up a site to act as a central repository for PHP libraries
>See PEAR. Unless you mean all the 3rd-party libraries like Oracle
>liboci8, libmysqlclient, libgd, openldap, ucd-snmp, etc.. That simply
It probably should, somehow. I don't think anyone is necessarily laying
your door, Rasmus, but it's something that's vitally needed.
>Surely there are things we can improve upon, but the current statement of
>the problem whichs assumes that Perl and Java are lightyears ahead of PHP
>when it comes to extending their functionality just isn't true. They face
>many of the same problems PHP does. When you have something that can
>interface with literally hundreds of 3rd-party libraries, the build system
>is going to be complex. And there are going to be versions of libraries
>that don't work with certain versions of other libraries. If Oracle
>decides to export a global symbol in liboci8 that clashes with a global
>symbol in some other 3rd-party library, then the PHP build breaks. There
>isn't much we can do about this. We do not control these 3rd-party
>libraries nor is there any way we possibly could control these. We can
>try to come up with a workaround, of course, but that is about the extent
>of it. The Perl, Python and Java camps have *exactly* the same issues.
My understanding of Java workings (others here use it - I don't) is that
is often as simple as adding another JAR file in your classpath. Except
like PDFLib which provide an SO file, it's pretty much never that easy.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]