RE: [PHP] Re: The future of PHP -- accessory libraries
Here's an idea. Provide commercial PHP support for ISP's for a fee. Yearly subscriptions ? via email? > -Original Message- > From: Brian Tanner [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 29, 2001 4:55 PM > To: [EMAIL PROTECTED] > Subject: RE: [PHP] Re: The future of PHP -- accessory libraries > > > Great idea. I think a section discussing configuration options, suggested > configurations, and general info for ISPS would be great. > > I just got a dedicated server and will be doing web hosting, and I think it > would be extremely helpful. > > (if anyone needs cheap hosting, let me know -- I have tons of bandwidth I > need to use up to make my money back) > > Brian Tanner > Project Manager > Zaam Internet Solutions > Toll Free: 1-866-225-2675 > [EMAIL PROTECTED] > http://www.zaam.com > > -Original Message- > From: Richard Heyes [mailto:[EMAIL PROTECTED]] > Sent: August 29, 2001 1:53 PM > To: Rasmus Lerdorf > Cc: PHP General > Subject: RE: [PHP] Re: The future of PHP -- accessory libraries > > > > So it looks like this is mostly a documentation issue. We have not done a > > good job educating the ISPs out there. But they should have been able to > > figure this out by looking at how PHP is packaged by the various > > distribution vendours. > > Perhaps a section in the manual dedicated to ISP related information? > -- > Richard Heyes > > > > -- > 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] > -- 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]
RE: [PHP] Re: The future of PHP -- accessory libraries
Great idea. I think a section discussing configuration options, suggested configurations, and general info for ISPS would be great. I just got a dedicated server and will be doing web hosting, and I think it would be extremely helpful. (if anyone needs cheap hosting, let me know -- I have tons of bandwidth I need to use up to make my money back) Brian Tanner Project Manager Zaam Internet Solutions Toll Free: 1-866-225-2675 [EMAIL PROTECTED] http://www.zaam.com -Original Message- From: Richard Heyes [mailto:[EMAIL PROTECTED]] Sent: August 29, 2001 1:53 PM To: Rasmus Lerdorf Cc: PHP General Subject: RE: [PHP] Re: The future of PHP -- accessory libraries > So it looks like this is mostly a documentation issue. We have not done a > good job educating the ISPs out there. But they should have been able to > figure this out by looking at how PHP is packaged by the various > distribution vendours. Perhaps a section in the manual dedicated to ISP related information? -- Richard Heyes -- 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]
RE: [PHP] Re: The future of PHP -- accessory libraries
> So it looks like this is mostly a documentation issue. We have not done a > good job educating the ISPs out there. But they should have been able to > figure this out by looking at how PHP is packaged by the various > distribution vendours. Perhaps a section in the manual dedicated to ISP related information? -- Richard Heyes -- 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]
Re: [PHP] Re: The future of PHP -- accessory libraries
Considering that they haven't figured out how to use the spell checker, does it surprise you that they haven't figured out how to do an dynamic load (apxs) of PHP? Or save their last good configuration (config.status). mark C. -- The phrase "computer literate user" really means the person has been hurt so many times that the scar tissue is thick enough so he no longer feels the pain. -- Alan Cooper, "The Inmates are Running the Asylum " - Original Message - From: "Geoff Caplan" <[EMAIL PROTECTED]> To: "PHP General" <[EMAIL PROTECTED]>; "Rasmus Lerdorf" <[EMAIL PROTECTED]> Sent: Wednesday, August 29, 2001 2:58 PM Subject: [PHP] Re: The future of PHP -- accessory libraries > Hi folks > > I asked my ISP to flesh out their negative comments about adding libraries > to PHP. > > This is their reply - is there anything in this, or are they > misunderstanding the situation? > > > > We run servers. We want to compile stuff from source, for obvious reasons! > As such, the question is simple and obvious: why does so much in PHP rely > on the core's compile-time. Why can't there be run-time or DSO inclusion > later on, as with Perl. Basically, PHP has really screwed up in this > monolythic design which was all very well when it was a simple templating > system, but now it's grown to a full-grown language, the scalability, > flexibility and namespace issues are becoming untennable. I note that > something called "Pear" appears in later compilations of the PHP core. I > assume this is some attempt at including Perl's library system and, > eventually, a CPAN-a-like? > >>> > > I'm not so sure why they prefer to compile from source - why wouldn't they > trust a professional distro? > > 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]
Re: [PHP] Re: The future of PHP - accessory libraries
Rasmus Lerdorf wrote: > > Exactly. When you do ./configure --with-foo=shared; make > > then modules/foo.so will appear magically and you can dl() that or load it > > using "extension=foo.so" in your php.ini. You don't have to recompile > > PHP. > > > > -Rasmus > > I am afraid that is only theory. I tried that for the snmp module and all I get > > is a linker error about unreferenced symbols, when I try to load it. Which symbols? This is the error message I get: Warning: Unable to load dynamic library '/usr/local/lib/php/modules/snmp.so' - ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/php/modules/snmp.so: symbol alloc_globals: referenced symbol not found in /usr/local/apache/htdocs/snmp.php on line 3 Heiko -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
At 11:13 29-08-01, Geoff Caplan wrote: >I am not very technical, as you will have gathered. But all I can do is pass >on the view of my (rather good) ISP. They offer Java, Perl and PHP, and say >that they find PHP much the most difficult to extend. Can you elaborate on what you (or they) mean by 'extend'? This statement simply appears fairly odd, and I want to understand it better. Who knows, we may even do something about it, God forbid :) Zeev -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
> > Exactly. When you do ./configure --with-foo=shared; make > > then modules/foo.so will appear magically and you can dl() that or load it > > using "extension=foo.so" in your php.ini. You don't have to recompile > > PHP. > > > > -Rasmus > > I am afraid that is only theory. I tried that for the snmp module and all I get > > is a linker error about unreferenced symbols, when I try to load it. Which symbols? -Rasmus -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
Rasmus Lerdorf wrote: > > That's not allowing me to simply dl() an SO file, because I don't have the > > SO file to start with - that's what I was trying to get at. If I have > > to reconfigure > > everything, there's not much point, I don't think. Unless I'm missing > > something > > obvious. I'd like to be able to simply have an SO file I can dl() > > without recompiling. > > Or are you saying that that configure statement WILL create an SO file > > that can > > be dl()ed later, without recompiling PHP? > > Exactly. When you do ./configure --with-foo=shared; make > then modules/foo.so will appear magically and you can dl() that or load it > using "extension=foo.so" in your php.ini. You don't have to recompile > PHP. > > -Rasmus I am afraid that is only theory. I tried that for the snmp module and all I get is a linker error about unreferenced symbols, when I try to load it. Heiko -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
> Exactly. When you do ./configure --with-foo=shared; make > then modules/foo.so will appear magically and you can dl() that or load it > using "extension=foo.so" in your php.ini. You don't have to recompile This is very good news! I must have mis-rad the manual on this part!! Is there any way to make these extensions with out making it all? Such as a "make extensions ---extension=foo.so" , Is there any plan for this? Thanks, CCMA -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
> That's not allowing me to simply dl() an SO file, because I don't have the > SO file to start with - that's what I was trying to get at. If I have > to reconfigure > everything, there's not much point, I don't think. Unless I'm missing > something > obvious. I'd like to be able to simply have an SO file I can dl() > without recompiling. > Or are you saying that that configure statement WILL create an SO file > that can > be dl()ed later, without recompiling PHP? Exactly. When you do ./configure --with-foo=shared; make then modules/foo.so will appear magically and you can dl() that or load it using "extension=foo.so" in your php.ini. You don't have to recompile PHP. -Rasmus -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
Rasmus Lerdorf wrote: >>Something which seems to not be a viable option for most things is SO >>files. For some reason, the only "real" way (documented) to get >>things into PHP is to compile them all into PHP. I've used the pdflib >>SO file and just used dl() to bring it in - works like a champ. Pity I >>can't do that for gd and other things. I don't NEED these things >>compiled in to PHP for every page request, yet the only method that's >>ever worked for me is by compiling them directly in. Most packages >>don't give PHP specific instructions, and even the couple that do >>don't appear to give instructions on how to make SO files. >> > >Hrm.. Something like > >./configure --with-gd=shared,/home/rasmus/gd-2.0.1 --with-jpeg-dir=/usr > >Doesn't work? If not, please file a bug report. It certainly should. > >I am not disagreeing that things could be improved, but I would like to >see some realistic suggestions. We cannot maintain all 3rd-party libaries >that PHP connects to. That should be obvious. We don't have the >resources, nor are we legally able to in some cases. > That's not allowing me to simply dl() an SO file, because I don't have the SO file to start with - that's what I was trying to get at. If I have to reconfigure everything, there's not much point, I don't think. Unless I'm missing something obvious. I'd like to be able to simply have an SO file I can dl() without recompiling. Or are you saying that that configure statement WILL create an SO file that can be dl()ed later, without recompiling PHP? -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
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]
Re: [PHP] Re: The future of PHP - accessory libraries
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.ph
Re: [PHP] Re: The future of PHP - accessory libraries
> Something which seems to not be a viable option for most things is SO > files. For some reason, the only "real" way (documented) to get > things into PHP is to compile them all into PHP. I've used the pdflib > SO file and just used dl() to bring it in - works like a champ. Pity I > can't do that for gd and other things. I don't NEED these things > compiled in to PHP for every page request, yet the only method that's > ever worked for me is by compiling them directly in. Most packages > don't give PHP specific instructions, and even the couple that do > don't appear to give instructions on how to make SO files. Hrm.. Something like ./configure --with-gd=shared,/home/rasmus/gd-2.0.1 --with-jpeg-dir=/usr Doesn't work? If not, please file a bug report. It certainly should. I am not disagreeing that things could be improved, but I would like to see some realistic suggestions. We cannot maintain all 3rd-party libaries that PHP connects to. That should be obvious. We don't have the resources, nor are we legally able to in some cases. -Rasmus -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
> 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. > 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. > 3) Actively encourage library developers to provide plugin binaries, or do > it for them if need be, at least for the most important libraries You mean PHP extensions? > 4) Do a regression test for each library once installed, and certify that it > does not break the core PHP application Impossible to do on the 50+ platforms PHP runs on. > 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. 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. -Rasmus -- 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]
Re: [PHP] Re: The future of PHP - accessory libraries
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. > > > >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? > I'm in complete agreement. Something which seems to not be a viable option for most things is SO files. For some reason, the only "real" way (documented) to get things into PHP is to compile them all into PHP. I've used the pdflib SO file and just used dl() to bring it in - works like a champ. Pity I can't do that for gd and other things. I don't NEED these things compiled in to PHP for every page request, yet the only method that's ever worked for me is by compiling them directly in. Most packages don't give PHP specific instructions, and even the couple that do don't appear to give instructions on how to make SO files. Increased use of SO files would, I think, make everyone's lives a lot easier. Michael Kimsal http://www.tapinternet.com/php/ PHP Training Courses 734-480-9961 -- 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]
RE: [PHP] Re: The future of PHP -- accessory libraries
> I love PHP, but for the following reason it could be the death of it. All > the PHP intellectuals stand up, get together, and solve this problem, or at > least give us some reassurance. (I'm only a newbie after all). :) 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 -- 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]
RE: [PHP] Re: The future of PHP -- accessory libraries
I love PHP, but for the following reason it could be the death of it. All the PHP intellectuals stand up, get together, and solve this problem, or at least give us some reassurance. (I'm only a newbie after all). :) -Original Message- From: Dan Harrington [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 6:11 AM To: Geoff Caplan; [EMAIL PROTECTED] Subject: [PHP] Re: The future of PHP -- accessory libraries Geoff Caplan said: > I would just like to highlight an issue which I feel has a negative effect > on the acceptance of PHP. > This is the difficulty of finding, downloading, compiling and installing the > various PHP libraries not included in the core distribution. Amen. As a member of a back-to-front web-design firm, we have resorted to hosting many of our customers in-house simply because the ISP that is currently hosting them either refuses to update accessory libraries, refuses us accessibility to update them ourselves, and/or treats the entire idea of their deficient system as incredulous. As a result, we have had certain projects that we had originally budgeted 2 days development and implementation time blow up into 2 month every-other-day negotiation with a hostile ISP complete with phone tag, additional agreement signing, and ultimately domain name transferring (which we should have done in the first place). One thing that I am _shocked_ has fallen by the wayside is payflow pro implementation. Until a short while ago, everyone I spoke with at Verisign tech support about PHP SDK implementation treated PHP like a dirty word and refused to help with it. Messages on php-general were answered by numerous "uh, yeah -- tell me how you do it when you find out" with conflicting answers from those who had an idea on how to get it to work. There are plenty of work-arounds if you're running your own show, but if you are dealing with a semi-hostile ISP, you are in for it. The ISP wouldn't give us info on where the CERTS were stored (because of security issues they said) so we couldn't put an environment variable pointing to them and use an exec() or passthru() to make it work either. And then the SSL conflicts with payflow pro SDK were laughable. How else would you want to use payflow pro except under an SSL environment? Don't get me wrong, I'm a *rabid* supporter of PHP and if not for it I'd certainly not be where I am right now. :-) My $0.02, Dan Harrington > -Original Message- > From: Geoff Caplan [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 27, 2001 4:26 AM > To: [EMAIL PROTECTED] > Subject: [PHP] Re: The future of PHP > > > Hi folks > > I would just like to highlight an issue which I feel has a negative effect > on the acceptance of PHP. > > This is the difficulty of finding, downloading, compiling and installing the > various PHP libraries not included in the core distribution. Many quite > important libraries seem to be persoanl projects which are not supported by > the core team, and are hosted on sites that can be down for days at a time. > On Linux, many still require a re-compile, there is no documentation > standard, and no central repository. This compares badly with platforms such > as Perl and Java, who tackled this issue long ago. > > My own ISP, who is one of the few to offer all PHP & MySQL upgrades as they > are released, complains about this bitterly. The upshot is that shared > hosting rarely offers more than the core functionality, which can be very > restrictive. Setting up your own server can be daunting and time consuming - > and the commercial distros such as Zend and Nusphere don't seem to have > tackled the library issue either. > > In terms of acceptability in the market, I suspect that this creates a > negative impression. It seems to me that this is a quite central issue if > PHP is to be perceived as a mature platform for building mission critical > systems. I do hope that the development team, and those such as Zend who are > committed to the future of PHP give this some attention. > > 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]
