Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35130
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
Cc: PHP internals <internals@lists.php.net>
Message-ID: <F879F582-1DF5-4298-91BA-A591AB9ADA1B@pooteeweet.org>
To: Lester Caine <lester@lsces.co.uk>
In-Reply-To: <47A58686.60707@lsces.co.uk>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Sun, 3 Feb 2008 10:56:08 +0100
References: <01c801c865d8$2e837e90$c6fc1f3e@foxbox> <14581063.20080203002104@marcus-boerger.de> <005201c8660f$66a2b160$c6fc1f3e@foxbox> <47A58686.60707@lsces.co.uk>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.092, required 6, AWL -0.01, RDNS_DYNAMIC 0.10)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 03.02.2008, at 10:16, Lester Caine wrote:

> Steph Fox wrote:
>> Hi Marcus,
>>> what I want is php-src as minimum you can depend on. And php- 
>>> default as
>>> release managers playground. The RM can then say what he thinks is  
>>> mature
>>> enough to make it into a release.
>> What _I_ want is a PHP core that is really core. By that I mean  
>> things like: date, spl, pcre, zlib, filter, simplexml, core-ish  
>> stuff such as PDO (no PDO drivers, unless we bundle SQLite as we  
>> could/should IMHO so there's a working DB for all), and underlying  
>> libs like libxml and mysqlnd that will make life easier for the  
>> many. I think what is distributed with PHP should be built-in and  
>> enabled by default, and it should include the basic essentials for  
>> making a simple website without anything else being added - and  
>> nothing more.
>
> This opens another can of worms :(
> Why include installation specific stuff in the core. MySQL was  
> dropped as the default for a reason lets not reintroduce it.
> Not bothering much WITH MySQL ( other than ensuring that SQL  
> generated in my projects will still run on it ) I see that this new  
> mysqlnd module is intended to SUPPORT PDO. Is THIS the way forward,  
> building native drivers that can be used via PDO or is it just a  
> another indication that one needs both PDO and a native driver?

I am also not sure if including mysqlnd in PHP core is the way to go.  
However I would not be generally opposed to including it in the PHP  
distribution.

So just to make sure that this list is also aware of what has spawned  
out of the PDO discussion. One of the proposals has been to keep PDO  
driver development in PECL and therefore no CLA'ed stuff would be in  
php-src. The obvious problem is that currently PECL<>core do not  
really have the necessary concepts in place to make this happen,  
though the ideas necessary to make this work predate even PDOv1.

Very long ago some people have formulated the vision that a PHP  
release would be similar to that of a Linux distribution.

PHP core ~ Linux Kernel
Various PECL extensions ~ Various OSS extensions

Some Linux Distributions also go so far to include some closed source  
components. I doubt that we want to go there, but we might want to  
include CLA'ed stuff. However that is beyond the discussion of this  
thread. This thread is about discussing if there is a better way to  
handle PECL packages.

Correct me if I am wrong or if I am missing something, but currently  
things work more or less like this. I think its important that we get  
an understanding of how things are right now and what the issues are,  
before we go off and solve them (maybe with the above mentioned  
approach):
- most new extensions these days begin their life in PECL
- generally PECL extensions are expected to follow internals CS (but  
they are not really checked if they do so)
- most extensions are not dramatically changed before inclusion to fit  
PHP core, they either fit or they do not .. most extensions are  
actually either developed with the idea of eventually being included  
or they will most likely never make it into core (Steph already gave  
an example, that some PECL extensions tend to be much liberal with the  
use of Exceptions than is currently accepted in php-src)
- if an extension is added to php-src, it is done through symlinking  
the PECL and php-src CVS
- a few extension are also removed from php-src .. I am not quite sure  
how the process is there, but I presume the code is removed in php-src  
and checked into PECL CVS
- ... (please complete this list)

regards,
Lukas