Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35175
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.147 cause and error)
Message-ID: <00f501c86743$e5122320$c6fc1f3e@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Derick Rethans" <derick@php.net>
Cc: "Marcus Boerger" <helly@php.net>,
	"internals" <internals@lists.php.net>
References: <01c801c865d8$2e837e90$c6fc1f3e@foxbox> <14581063.20080203002104@marcus-boerger.de> <005201c8660f$66a2b160$c6fc1f3e@foxbox> <alpine.DEB.0.98.0802041032220.10785@kossu.ez.no>
Date: Mon, 4 Feb 2008 15:37:42 -0000
Organization: Zend Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
From: steph@zend.com ("Steph Fox")

Hi Derick,

> 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!

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.)

If everything in PECL were classified, it'd be much easier for people to 
figure out what to load and when. A simple 'justification' line alongside 
the classification would be immensely helpful, assuming the info in 
package.xml is made obvious via the installer. You'd need a few extra 
sections in package.xml, e.g:

<version>2.0</version>
<status>stable</status>
<classification>
 <rank>A2</rank>
 <reason>specialist interest</reason>
</classification>
<maintenance>
 <level>active</level>
 <lastfix>10/01/08</lastfix>
 <bugsopen>5</bugsopen>
</maintenance>

That tells users and sysadmins alike everything they need to know about that 
extension and allows them to make an informed decision about installing it, 
or not, as the case may be. Some of that info could even be autogenerated...

Anything _not_ in 'the A1 pack' would need to be downloaded individually, 
via a system we don't have yet (again, speaking as a Windows user). Another 
thing would be to offer downloads by classification, e.g. 'pecl install A1'.

- Steph




>
> regards,
> Derick
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>