Zeev Suraski wrote: > 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.
:) That's may be true. > > 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. I agree. All extensions that is not required for building base PHP should be moved to PECL. If we need to distribute some extensions as php-x.x.x.tar.gz we should pick up module source from PECL. This way, we can release bug fix for certain module _very_ quickly. IMHO, only ext/standard (and very few modules if any) should be in php4 repository. With this policy, noone has to feel their extension is banished to Siberia. -- Yasuo Ohgaki > > 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
