Geoff (and the list) ...
You have presented an excellent, well-reasoned case, which I endorse 100
percent.
You also raised issues I have not had to consider, as my development has
been for lightly loaded servers under my control, with only the PostgreSQL
and MySQL libraries required. I'll also acknowledge that since they have
been up and in production for several months, with no problems, I've felt
no compulsion to upgrade them, applying the "if it's not broken, don't fix
it." philosophy.
But I had a problem last summer that illustrates your case; involving the
Solid database and the Perl libraries, though not with PHP as it never got
that far. Solid had made radical changes to the API, and the existing Perl
drivers would not work. The maintainer knew of the problem but had not had
time to update them. He was supportive, but frustrated. Solid were
singularly unresponsive. That left me with three choices: Learn Perl and
fix the drivers myself, use an earlier version of Solid, or pick another
database.
Despite the "You have the source" credo of Open Source, the first option
was not feasible. Solid would not sell a previous version, so that ruled
out the second. The site is now running off PostgreSQL.
Given that experience, I understand the ISP's position. Large, high-traffic
commercial sites need a level of confidence and security. With growth comes
responsibility, and we are heavily dependent on the libraries for
everything other than core functionality. Your suggestions are sound and
get my vote. I am keen to hear opinions from others.
Regards - Miles Thompson
At 11:29 AM 8/28/01 +0100, Geoff Caplan wrote:
>Rasmus wrote
>
> > This is solved by people who roll distributions. Debian, Mandrake,
> > RedHat, FreeBSD, etc. It is very simple to add new features to an
> > existing PHP setup through these binary distributions of PHP, even for
> > newbies. Once you know your way around PHP and its build system, you will
> > probably want to build you own though. It's not that difficult.
> >
>
>Rasmus, I really am concerned if you think that this problem is "solved". In
>my own experience, talking to ISPs and developers, this is a major roadblock
>to the development of PHP as a platform for both sophisticated solutions on
>shared servers, and major mission critical systems.
>
>I felt that the contribution by Dan Harrington was an eloquent description
>of the kind of issues that arise. My own ISP is pushing people towards Perl
>and Java for precisely this reason, if they want more than the functionality
>in the core build of PHP.
>
>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"?
>
>Now compare this with Perl or Java, where they simply plug in the new
>functionality without any significant risk of breaking their server setup.
>
>All this surely applies with even more force for a corporate IT department
>evaluating PHP for a mission critical project.
>
>If you don't agree that this is a major issue that needs to be addressed, I
>fear for the future of PHP.
>
>If I was Zend, with a major interest in promoting PHP as a professional
>enterprise solution, I would be supporting something like the following:
>
>1) Propose a library documentation standard based, say, on CPAN and get it
>adopted by the community
>2) Set up a site to act as a central repository for PHP libraries
>3) Actively encourage library developers to provide plugin binaries, or do
>it for them if need be, at least for the most important libraries
>4) Do a regression test for each library once installed, and certify that it
>does not break the core PHP application
>
>An initiative of this kind would go some way to helping PHP to catch up with
>competitive platforms.
>
>However, judging from this current thread, the development team don't see
>this as a priority, so I guess that it won't happen unless the user
>community makes a strong case for it.
>
>What do people think?
>
>Geoff Caplan
>
>
>
>--
>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]
--
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]
