I tend to agree that completely separating PHP from the modules does cause a problem when it comes to support modules, etc. However, IMHO I feel that as the numbers of modules written for PHP increases there becomes a greater and greater need to separate modules from the core of PHP.
When it comes to bug reporting/fixing, perhaps it's feasible to completely separate bug reporting for each module from PHP itself? For example, if each module is maintained completely separately from PHP with it's own version # then there should also be a separate bug reporting system for bugs found with that module. Also, on that note, is there any hard and fast standard in place for modules/extensions and the minnimum PHP version those modules support? I.e. is there anything that is designed to prevent me from trying to load a module in PHP 4.0 when it won't work with any version of PHP less than 4.2? I mean more than it throwing an error at compile-time of course. When I look at PECL, I envision a system where modules are completely separated from the PHP core. Each module and their maintainer(s) (whomever they are) deal with their own bugs for that module, modules have minnimum PHP core versions for which they work with, etc. We could make this easier by providing a source-forge type of cookie-cutter bug tracking system for each module, and perhaps by making the modules themselves clearly independent of PHP. I'd like to see a system for modules where what modules PHP uses is not defined at compile-time at all by a ./configure statement. Rather, what modules are being used are defined in some sort of configuration file (where the configuration parameters for those modules are also located) and the modules are loaded dynamically. I should be able to go download the GD module and stick it in a subdirectory of /usr/local/lib/php and then edit my modules.conf (or something) file: <module name="gd"> Allow_jpeg=true Allow_tiff=false </module> These are all just thoughts I have.. Feedback is more than welcome. I think a system such as this would accomplish a number of (in my mind) benfitial things: 1) Faster and easier installations of PHP By removing all of those compile-time ./configure options it will make PHP much easier to compile and install. Problems with a single module at compile-time won't stop a user from getting PHP running, and if there is a problem when the module is dynamically loaded it will be easier to figure out what's going wrong. 2) More accurate and managable module maintaing If modules are completely separated from PHP itself, then the status of a particular module, the people who are maintaining it, news about the modules, etc. will be easily found. There are more, but it's late and I'm going to get to sleep :) Like I said, feedback is more than welcome and I'd love to work with whomever is interested to move PHP in this direction. Cheers, John >-----Original Message----- >From: Dan Hardiker [mailto:[EMAIL PROTECTED]] >Sent: Thursday, January 02, 2003 3:59 AM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: Re: [PHP-DEV] PHP in 2003 (leading to PHP 5) > > >> [...] >> different distribution packages can be >> built when php releases occure, such as 'php core' which >would contain >> the 'most important' stable extensions, 'php stable' which would >> contain all stable extensions, and 'php bleeding' which could be a >> package with the latest development snapshot at time of release. >> >> With this also extensions now can take on a life of their own, >> releasing at different times than php, and visaverse. I think this >> would make releasing new versions of php much more manageable. > >>From my past experiance, Ive found this sort of idea to be great - if >>the >modules are retrieved else where, otherwise you end up with a >support nightmare. > >Currently in the bug tracker we only need to ask what version >of PHP they have and we automatically know what version all >the of the modules are as they come bundled. If all the >modules are updateable independantly of the PHP release having >"PHP x.x.x" installed is no longer enough release information, >we (via the end user) would also have to gather the version >number for each module - ouch. > >Not to mention the painful testing! [eg:] I have 4 >installations running 4 different versions of PHP for >regression testing and bug fixing. If I relied on 3 different >modules and wanted to check 2 versions of each, I would need 4 >* 3 * 2 (24) installations - just to test. > >Im not against the concept of modules, but Id encourage the >idea to be well thought out (especially the impact) as well as >encouraging them to be thought more of "plug-ins" which are >independant and may well be "upgraded". > ></concerned> > > >-- >Dan Hardiker [[EMAIL PROTECTED]] >ADAM Software & Systems Engineer >First Creative > > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
