Zeev
At 09:50 24/06/2003, James Cox wrote:
> > Since there's been a lot of talk about disabling mysql by > default (and > having another option available), the PostgreSQL people are > pretty excited > about this and are keen to see what can be done about getting > postgres > enabled by default instead. >
I certainly don't speak for all. But I would like to throw my hat in on this -- why not stop enabling stuff by default ... We really don't need to. Many developers complain that our users are stupid, or whatever other discrediting statement that seems to be in fashion. By educating them (ie, helping them along a little, requiring that they get to know ./configure options) the chances are that they will not appear to be quite so stupid anymore.
Ok. Getting to a point: bundling things is PHP telling users what tools they should use. Yes, there is --without-<foo> but it doesn't help a newer user, and it certainly doesn't show that we are adhering to some sort of standard about enabling by default, and bundling comes into it too.
Therefore, I propose that we:
-- limit bundled code to _only_ code that is either hard to find and install or we have chosen to fork (eg, gd), or is core code which we can not live without. (i.e. the build fails -- eg, pcre).
-- limit enabled-by-default extensions to only those which have a significant reasoning behind it (ie, like pcre, which is core code and would cause breakages without it), AND comes along with 10 positive votes for enabling.
I admit that perhaps these guidelines are not encompassing, and I can already see loopholes. I encourage other members of this list to propose changes and enhancements, but one thing we must prevent is this notion of bundling/enabling code based on the whim and fancy of one or a few developers. PHP doesn't need to become known as PHP with CPANesque bloat attached on.
I look forward to the day where we can distribute a version of php with just the engine, the build system, main/ and ext/standard - the real core of PHP.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
