Re: The future of PHP - accessory libraries

Rasmus Thanks for your very full and thoughtful reply > 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. 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. As other responses have pointed out, Perl and Java, while not perfect in this area, do seem to offer a number of advantages. You ask for practical suggestions. Well, it is clearly a fair comment to say that you can't offer 200 certified libraries on every platform that compiles PHP. But you could surely make a very large dent in the problem with a very much smaller initiative. 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. You could also prioritise the libraries. I would suggest that there are a number that are clearly of strategic importance for using PHP in mission critical settings: XML, encryption, graphics etc. I would guess that perhaps 20 or 30 libraries would cover 80% of user needs. The development team would have a pretty good idea of the priorities, I would imagine, or you could run a poll through this list. So if you define the initial task as providing a practical way to add around 25 certified libraries to RedHat and compatible distros (ideally on the fly), the issue would surely be more managable, yet any solution would make a big impact on the problem. I guess that something as convenient as the Apache module system would be the ideal for ISPs. I am not qualified to comment on the best technical solution, but I suspect the mechanisms are already in place in the current version of PHP. I have no direct experience of this field, but I suspect that companies like RedHat and SuSE might be open to some kind of partnership here and sponsor the project. Or Zend ( or RedHat or SuSE) could develop an extended distro as a commercial product - I don't see that ISPs and corporates would object to paying a modest sum for a tested and certified distro with extended functionality. Obviously, coders like to code. The other stuff is just an unwelcome distraction. But there are two other issues that contribute greatly to the viability of any application - documentation and installation/configuration. With documentation, I am sure that the whole community would congratulate the PHP team on what they have achieved. It would be great if you could make similar progress with installation/configuration. What do you think? Does any of this suggest a practical way forward? Geoff Caplan