Re: enabling everything by default

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