Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:2685
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: "'Chris'" <blankey-phpdev@squiz.net>,
	<internals@lists.php.net>
Date: Tue, 24 Jun 2003 07:50:54 +0100
Message-ID: <00e601c33a1c$f58e39e0$0200a8c0@23i.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <5.2.0.9.0.20030624163256.01107058@cooee.squiz.net>
Subject: RE: [PHP-DEV] enabling postgresql by default
From: james@imajes.info ("James Cox")
References: <5.2.0.9.0.20030624163256.01107058@cooee.squiz.net>


>=20
> Since there's been a lot of talk about disabling mysql by=20
> default (and=20
> having another option available), the PostgreSQL people are=20
> pretty excited=20
> about this and are keen to see what can be done about getting=20
> postgres=20
> enabled by default instead.
>=20

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.
=20