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
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
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
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
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
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]
[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] Re: The future of PHP - accessory libraries
Rasmus That's a pretty good list. And the Mandrake and Debian packages are every bit as complete. I am not as familiar with SuSE nor the fbsd port, but I would be very surprised if they were not very close to, if not better than, the current RedHat rpms. Thanks for the education - I have an ancient version of RedHat and didn't realise that things have moved on so much. When I upgrade I just compile the distro from the php.net. Now I know better... Perhaps there could be some notes about what the commercial distros can offer in the download area of the site - I suspect there are many who are not aware of this... What exactly is the ISP having trouble with? What is the error message? What sort of setup do they have? Or, is the problem really that they are just more familiar with other technologies and are just feeding you a line to get you to go away? I will pass on your post to them and ask them precisely that. I know they are using SuSE, but that has the reputation of being the best distro for integrating other applications, so I will try to get a better handle on what the problem is. Thanks again 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] Re: The future of PHP - accessory libraries
Being practical, the vast majority of serious PHP applications will be running on Linux. If you were to cover RedHat, and .rpm compatible distros such as SuSE, you would cover the requirements of perhaps the majority of users. But RedHat, SuSE, Mandrake, Debian and FreeBSD already have designated people who do exactly this. For example, have a look here: http://rpmfind.net/linux/RPM/rawhide/1.0/i386/PByName.html Note the php-* rpms: php-4.0.6-6 php-devel-4.0.6-6 php-imap-4.0.6-6 php-ldap-4.0.6-6 php-manual-4.0.6-6 php-mysql-4.0.6-6 php-odbc-4.0.6-6 php-pgsql-4.0.6-6 And before you go off and complain about all the missing ones, take a look at all the dependencies for the base php rpm: libbz2.so.1 libcrypto.so.2 libcrypt.so.1 libc.so.6 libcurl.so.1 libdb-3.2.so libdl.so.2 libfreetype.so.6 libgdbm.so.2 libgd.so.1.8 libjpeg.so.62 libltdl.so.3 libmm.so.11 libm.so.6 libnsl.so.1 libpam.so.0 libpng.so.2 libpspell-modules.so.1 libpspell.so.4 libresolv.so.2 libssl.so.2 libstdc++-libc6.2-2.so.3 libttf.so.2 libxml2.so.2 libz.so.1 That's a pretty good list. And the Mandrake and Debian packages are every bit as complete. I am not as familiar with SuSE nor the fbsd port, but I would be very surprised if they were not very close to, if not better than, the current RedHat rpms. I don't agree that we should take away the responsibility of creating these binary distributions of PHP from the distribution maintainers out there. If they are not doing a good job, or if there are specific problems with their packaging of PHP, submit a bug report to them. If they determine that something in PHP itself it preventing them from packaging it nicely, they will hopefully let us know and we can address it. What do you think? Does any of this suggest a practical way forward? Not really no, since I still don't have anything concrete to go on. I have heard that ..., someone said that it didn't work... Stuff like this doesn't really give us anything to sink out teeth into. What exactly is the ISP having trouble with? What is the error message? What sort of setup do they have? Or, is the problem really that they are just more familiar with other technologies and are just feeding you a line to get you to go away? -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]
[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? Well, I tend to prefer compile from source as well. I guess they simply don't realize that you can compile most of the extensions as shared libraries and configure what should be loaded at runtime in the php.ini file. 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. -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]
SV: [PHP] Re: The future of PHP - accessory libraries
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? I have to go with the (few) extensions/librarys provided by my ISP. If you don't run your own server, that's how it works with most ISPs, I think. Some ISP don't even run PHP4, they still use PHP3. If you don't agree that this is a major issue that needs to be addressed, I fear for the future of PHP. I agree 100%. Anders Nawroth - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [EMAIL PROTECTED] http://www.nawroth.com/ -- 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] Re: The future of PHP - accessory libraries
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]
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
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
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
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
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
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
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:
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. snip 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
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 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]
[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]
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]
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]
