Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39526
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
Message-ID: <4892E37B.8060804@macvicar.net>
Date: Fri, 01 Aug 2008 11:20:43 +0100
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Antony Dovgal <tony@daylessday.org>
CC: php-dev <internals@lists.php.net>
References: <4892E15D.1080004@daylessday.org>
In-Reply-To: <4892E15D.1080004@daylessday.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  Antony Dovgal wrote: > Hello all. > > I'd like to express
	my feelings on the "let's-enable-it-by-default" mood > that has emerged lately.
	> > Extensions enabled by default in 5.2: > ctype > date > dom > filter >
	hash > iconv > json > libxml > pcre > PDO > pdo_sqlite > posix > Reflection
	> session > SimpleXML > SPL > SQLite > standard > tokenizer > xml > xmlreader
	> xmlwriter > ----- > Total: 22 extensions > > Extensions enabled by default
	in 5.3: > ctype > date > dom > ereg > fileinfo - new, untested. > filter
	> hash > iconv > json > libxml > pcre > PDO > pdo_sqlite > Phar - new, untested
	> posix > Reflection > session > SimpleXML > SPL > SQLite > sqlite3 - new,
	untested > standard > tokenizer > xml > xmlreader > xmlwriter > ------ >
	Total: 26 extensions > > All of the newly enabled extension are still in development
	and none of > them are known to be stable enough to be even included into
	the core, > but for some weird reason they got even enabled by default (i.e.
	> officially recommended). > > So we now have 3 (three) SQLite extensions,
	all of them too slow to be > used in real life (because SQLite itself is
	slow), [...] 
	Content analysis details:   (-4.3 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	0.1 AWL                    AWL: From: address is in the auto white-list
Subject: Re: [PHP-DEV] enabling everything by default
From: scott@macvicar.net (Scott MacVicar)



Antony Dovgal wrote:
> Hello all.
> 
> I'd like to express my feelings on the "let's-enable-it-by-default" mood 
> that has emerged lately.
> 
> Extensions enabled by default in 5.2:
> ctype
> date
> dom
> filter
> hash
> iconv
> json
> libxml
> pcre
> PDO
> pdo_sqlite
> posix
> Reflection
> session
> SimpleXML
> SPL
> SQLite
> standard
> tokenizer
> xml
> xmlreader
> xmlwriter
> -----
> Total: 22 extensions
> 
> Extensions enabled by default in 5.3:
> ctype
> date
> dom
> ereg
> fileinfo - new, untested.
> filter
> hash
> iconv
> json
> libxml
> pcre
> PDO
> pdo_sqlite
> Phar - new, untested
> posix
> Reflection
> session
> SimpleXML
> SPL
> SQLite
> sqlite3 - new, untested
> standard
> tokenizer
> xml
> xmlreader
> xmlwriter
> ------
> Total: 26 extensions
> 
> All of the newly enabled extension are still in development and none of 
> them are known to be stable enough to be even included into the core, 
> but for some weird reason they got even enabled by default (i.e. 
> officially recommended).
> 
> So we now have 3 (three) SQLite extensions, all of them too slow to be 
> used in real life (because SQLite itself is slow),

This is just your opinion. SQLite is fast enough for mainly static data 
and its zero configuration setup makes it an ideal DB solution. Using 
MySQL for the sake of MySQL isn't always the answer.

Regarding there being three extensions, sqlite uses libsqlite v2. I'd 
remove it in a heartbeat if libsqlite v3 could read the database format 
but that currently isn't the case. I'm looking to it now to see if 
pulling out the db is possible.

ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its just 
another wrapper but without the PDO crap on top.

two PDO extensions
> (unmaintained, known to cause crashes), json (author's gone for a 
> burton; stability and necessity is arguable), fileinfo extension with no 
> tests and poorly written bundled lib known to cause crashes
> and we in fact *officially recommend them* by enabling them all by default.
> 
> So why should we even bother disabling something?
> Let's enable everything by default, most of the users use --disable-all 
> anyways!
> 
> I can agree that disabling something that was already enabled in 5.2 
> might create some confusion, but why enable scarcely created extensions 
> by default, especially if they are known to cause lost of obscure 
> problems in the past (like Phar)?
> 
> I mean completely no offense to the developers of these extensions, but 
> I would like them (extensions) to be thoroughly tested and mature first, 
> after that we can discuss the question of adding them to the core.
> And no, they must not be enabled by default unless they bring some 
> extra-useful functionality that the engine lacks (like SPL and 
> reflection do).
> 

If you have ideas on testing without enabling them or bundling in the 
build please do share. It's a chicken and egg situtation imho.

Scott