Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35230
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.94.239.7 as permitted sender)
Date: Wed, 6 Feb 2008 09:42:30 +0100 (CET)
To: Steph Fox <steph@zend.com>
cc: Marcus Boerger <helly@php.net>, internals <internals@lists.php.net>
In-Reply-To: <00f501c86743$e5122320$c6fc1f3e@foxbox>
Message-ID: <alpine.DEB.0.98.0802060940100.4967@kossu.ez.no>
References: <01c801c865d8$2e837e90$c6fc1f3e@foxbox> <14581063.20080203002104@marcus-boerger.de>
 <005201c8660f$66a2b160$c6fc1f3e@foxbox> <alpine.DEB.0.98.0802041032220.10785@kossu.ez.no>
 <00f501c86743$e5122320$c6fc1f3e@foxbox>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
Subject: Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
From: derick@php.net (Derick Rethans)

On Mon, 4 Feb 2008, Steph Fox wrote:

> > I see another issue after reading this, and that is that it makes it
> > much harder for users to depend on specific extensions just being always
> > available by default. It's important for application distributers to
> > have this core set of extensions to rely on. It's annoying enough that
> > some distributions (gentoo, freebsd) already use --disable-all and their
> > users then bugging us (or me) with "you should check that SPL is enabled
> > in your code".
> 
> Well, you should, while it's possible to disable it!

Uh, no? Most of those things (pcre and SPL) are absolutely necessary - I 
find it strange enough that they *can* actually be disabled. I refuse to 
make hacks in code just because some distributions fuck up the default 
installed extensions.

> Consider a distribution that has _only_ the essentials. Consider also a
> relatively small bundle of PECL extensions that ships alongside it. Say we
> classify them: everything that currently ships with core would be class A1 or
> whatever, as would anything else in PECL that is stable and considered likely
> to be useful to a wide range of users. Anything in that bundle is
> "recommended", and we make it very plain to sysadmins that they should install
> any of that bundle supported by their system. It includes things like (most)
> PDO drivers, SOAP, sqlite, zip, curl, json... all things that are currently
> shipped with the core but not necessarily (under doze at least) enabled by
> default. We educate PHP users to insist on 'the A1 pack'. We also make it
> _possible_ to operate PHP without 'the A1 pack', but I do just mean
> 'possible'. (In other words it should be possible to write a basic website
> using PHP as it comes, without adding or enabling anything.)

You really think that would work? You forget that for most shared 
hosters they just install PHP so that they can say they support it, but 
actually don't give a ratsass about what is actually supported.

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org