As I told Stig yesterday, I think the main problem with PECL right now is that when an extension is moved to PECL, its author gets the feeling as if it was banished to Siberia, and that has to be changed.
I think that the moving of extensions to PECL was supposed to address the problem of synchronizing the development schedule of a large number of extensions with the development schedule of PHP itself. There's validity in this point, and thus, certain extensions would indeed be better off in PECL. However, that shouldn't necessarily affect their existence in the PHP distribution - I think this has been discussed before. An extension CAN reside in PECL and yet, be included in the PHP distribution. One should not have anything to do with the other. When a PHP release (or RC) is packaged, there should be a list of PECL extensions that do make it into the release. The packager should have a list of those, and there should be some sort of an easy way for him to import the latest *stable* version of the extension. That way, non-esoteric PECL'd extensions do get to have their own release cycle while still being included in the PHP distribution. Zeev At 17:24 25/05/2002, Andi Gutmans wrote: >Hey guys, > >I just want to air my opinion on what happened with msession and PECL. >Although I have not always liked Mark's attitude in the past when it came >to coding conventions I do think that the move of msession into PECL >without consulting him nor php-dev was extremely wrong. >I personally don't hang around on IRC (no time) and the only mailing list >I follow closely is php-dev. I think that in general it has always been an >informal agreement that php-dev is the place to take such issues. >Now about the matter itself. I think one of the main benefit's of PHP over >the years is that it was very easy for users to get started. A single >download includes most extensions which are needed to develop web >applications. I don't think we should change this drastically meaning that >all *important* and main-stream extensions should stay in the core >including most of the SQL extensions, XML, XSLT, sessions, COM, bz2, zlib, >imap, gd, curl and so on. >I am aware that some of the extensions such as ircg, readline, fribidi can >be considered not very main stream and it does make sense to move some of >these into PECL. (I intentionally didn't mention where I think msession >belongs because that's not what I want to discuss in this Email). >I do feel that the main problem with PECL is that the only PHP users who >seem to know about it are people on the PEAR mailing list. I think if >you'll ask the average PHP programmer and ask him if he knows what PECL is >he'll have no idea. All he knows is the .tar.gz he downloads from php.net. >A long time ago I mentioned here that in order for me to support PECL we'd >have to make sure it is well advertised and it has to make it extremely >easy to download and install PECL extensions. I was thinking of possibly a >message at the end of ./configure mentioning that some extensions can be >gotten from PECL and an automatic way of listing PECL extensions and >downloading/building them into PHP. >My idea was something like the following: (From php4/) >./pecl-list <-- This would give a list and short description of all >extensions in PECL >./pecl-download FooBar <-- This would download FooBar and put it in ext/ >and run ./buildconf >Then the user could just run ./configure and configure with the downloaded >extension. Most users still prefer to statically build their extensions >and not use phpize although that could be optional. > >Once we have this kind of mechanism I think it'll be much easier for us to >move non-core extensions into PECL. As I mentioned before I still think >that the traditional core extensions should stay in the main PHP >distribution. PHP in embedded systems is rare and it's no excuse to remove >core extensions from PHP. People who want to build a naked PHP for >embedded systems can ./configure PHP accordingly! > >My 2 cents. > >Andi > > >-- >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
