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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
