Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35132
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Sun, 3 Feb 2008 12:24:35 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <452173393.20080203122435@marcus-boerger.de>
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Lester Caine <lester@lsces.co.uk>, PHP internals <internals@lists.php.net>
In-Reply-To: <F879F582-1DF5-4298-91BA-A591AB9ADA1B@pooteeweet.org>
References: <01c801c865d8$2e837e90$c6fc1f3e@foxbox> <14581063.20080203002104@marcus-boerger.de> <005201c8660f$66a2b160$c6fc1f3e@foxbox> <47A58686.60707@lsces.co.uk> <F879F582-1DF5-4298-91BA-A591AB9ADA1B@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
From: helly@php.net (Marcus Boerger)

Hello Lukas,

Sunday, February 3, 2008, 10:56:08 AM, you wrote:

> 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.

> - most new extensions these days begin their life in PECL

MySQLND was the last extension started in php-src and I don't even remember
when this was discussed (though in the current structure I like it there
pretty much). Anyway my idea is to start everything in PECL and
to to move everything out that can be moved out. And that includes all MySQL
extensions as well as SQLite. Only this way people will use the PELC
infrastructure. Otherwise we would just reduce functionality of PHP. And btw
nearly all linux distributions today offer a bunch of PECL extensions, and
for windows we offer DLLs for most PECL extensions for a long time now.

marcus

> - 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

We move the directory (or would drop the link).

> - ... (please complete this list)

> regards,
> Lukas




Best regards,
 Marcus