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
>unrealistic.
>
>>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
install Bundle::Apache
^^^^^^^^^^^^^^^^^^^^^^^
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
appropriate
MySQL libraries and compiled them on my system. PHP ships with MySQL
stuff now,
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
>won't happen.
>
It probably should, somehow. I don't think anyone is necessarily laying
this at
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
"extending"
is often as simple as adding another JAR file in your classpath. Except
for things
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]
