Re: Could some kind soul review these patches please.

There are certain extensions that can't be distributed alongside PHP because of license conflicts. Distributing these separately from a tree without such license restrictions is the only real solution I see short of dropping those extensions completely. A good example is the readline extension which we will have to remove from PHP due to a license conflict. -Rasmus On Thu, 14 Dec 2000, Zeev Suraski wrote: > At 01:04 14/12/2000, Matt McClanahan wrote: > >I'd like to see PEAR move in this direction. The benefits of having PHP > >include all extensions are definitely strong ones. However, as more > >extensions are added which apply to less users, PHP will inevitably grow > >larger than is justified by the benefits. Sure, as somebody with no > >worries regarding disk or cpu space, or bandwidth, I would probably prefer > >to grab everything in one tarball and build it all from there. But I > >think the time will come when this becomes impractical for users. In any > >case, available resources isn't the only consideration. > > I really don't think that these are real world issues. Disk space is dirt > cheap today. And so is bandwidth, when we're talking about the range of > hundreds of kilobytes, or a couple of megabytes at most. Including all > extensions in the PHP source tree does not waste any CPU time - Sascha's > latest and greatest build only includes the modules that are actually being > compiled-in in the PHP binary. > > I really fail to see a real-world reason to stop distributing any > remotely-popular extension along with PHP. Fact is, for someone who's used > to install PHP and the modules he likes by simply turning them on in > configure (and I think there's a huge number of such people), we'll be > doing a disservice by moving the modules away to a separate mechanism. > > >It would be beneficial to have an authoritative and automated mechanism > >for installing extensions on a system without recompiling PHP itself. It > >seems to me that this would go a long way in fostering the development of > >more extensions to PHP, assuming this is a direction that interests the > >PHP group. If such a system was in place, I think it would be good to > >pear down (So to speak) the number of extensions included in PHP. Some > >candidates I would consider, for various reasons, as 'non-core' are ccvs, > >cybercash, dotnet, fribidi, iisfunc, ircg, printer, and qtdom. > > Well, most of them are indeed non core. Some are probably more popular > than others (cybercash, for instance). Again, I fail to see the gain of > moving them away. > > This, by the way, has nothing to do with your suggestion for an automated > mechanism for building extensions, which is a good idea. > > Zeev > > > -- > Zeev Suraski <zeev@zend.com> > CTO, Zend Technologies Ltd. http://www.zend.com/ > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >