# enabling everything by default - Thread: https://externals.io/message/39525 - Original archive: https://news-web.php.net/php.internals/39525 - Started by Antony Dovgal on 2008-08-01T10:11:41+00:00 - Messages: 41 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/39525.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #39525 — Antony Dovgal — 2008-08-01T10:11:41+00:00 URL: https://externals.io/message/39525#39525 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), 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). -- Wbr, Antony Dovgal --- ## #39526 — Scott MacVicar — 2008-08-01T10:20:43+00:00 URL: https://externals.io/message/39525#39526 · In reply to: #39525 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 --- ## #39527 — Antony Dovgal — 2008-08-01T10:30:53+00:00 URL: https://externals.io/message/39525#39527 · In reply to: #39526 > ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its just > another wrapper but without the PDO crap on top. I know, I know. But why enable it by default (as well as PDO_SQLITE)? What's so extremely useful in this extension that every user needs it? > 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. Testing doesn't require enabling it by default. In fact, it doesn't even require putting the extension in the core, though this surely increases the the amount of feedback. Developers should test their extensions, not users. -- Wbr, Antony Dovgal --- ## #39528 — Scott MacVicar — 2008-08-01T10:41:26+00:00 URL: https://externals.io/message/39525#39528 · In reply to: #39527 Antony Dovgal wrote: > > > […] > > I know, I know. > But why enable it by default (as well as PDO_SQLITE)? What's so > extremely useful in this extension that every user needs it? The zero configuration aspect, the ability to just throw up a database in place of your own over complicated storage format. Sure all hosts have MySQL but if you're shipping a product then sometimes its simpler to just bundle a SQLite DB. Clientside apps are also moving forward with SQLite, Firefox 3.0, Google Gears, Adobe AIR and just about every Apple product. I've been writing PHP scripts to start using the data. I'm happy to disable PDO by default and have you force it on like mysql or any of the others. > > > […] > > Testing doesn't require enabling it by default. > In fact, it doesn't even require putting the extension in the core, > though this surely increases the the amount of feedback. > Developers should test their extensions, not users. > Yep, we're already using it here in several applications and I have a few side projects using it. Test coverage was good, about 80%. I'll be doing more before alpha 2. Scott --- ## #39529 — Antony Dovgal — 2008-08-01T10:43:19+00:00 URL: https://externals.io/message/39525#39529 · In reply to: #39528 > > […] > > The zero configuration aspect, the ability to just throw up a database > in place of your own over complicated storage format. Sure all hosts > have MySQL but if you're shipping a product then sometimes its simpler > to just bundle a SQLite DB. None of this requires enabling it by default. -- Wbr, Antony Dovgal --- ## #39530 — Robert Lemke — 2008-08-01T10:44:20+00:00 URL: https://externals.io/message/39525#39530 · In reply to: #39527 Hi folks, Am 01.08.2008 um 12:30 schrieb Antony Dovgal: > > > […] > > I know, I know. > But why enable it by default (as well as PDO_SQLITE)? What's so > extremely useful in this extension that every user needs it? FWIW: In TYPO3 5.0 we rely on PDO_SQLITE and use it as the default database directly after the installation of TYPO3. Not because SQLite is such a performant database, but rather because we can use it without having to ask the user for any configuration / credentials. Later on the user has the opportunity to move her data into a more sophisticated database such as MySQL or Oracle. So from our point of the universe: Please keep PDO_SQLITE enabled, it makes our lives much easier. Cheers, Robert --- ## #39531 — Pierre Joye — 2008-08-01T10:55:05+00:00 URL: https://externals.io/message/39525#39531 · In reply to: #39529 > > > […] > > None of this requires enabling it by default. One of the reason of the PHP success is its feature richness. ISP, good or bad, enables what we enable. You can see that in the extension usage statistic (from nexen.net). They have to be taken with a bit of salt but they represent a good way to see what actually happens out there. I heard solutions like "educating the ISPs" and seriously that's a sweet dream and may not reflect their needs. An extension not enabled by default is often not used for this exact reason: it is not enabled by default. So my thoughts are really simple, unless disable-all is used, enable everything possible as long as the deps are found (or if there is no dep). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #39532 — david.zuelke@bitextender.com — 2008-08-01T11:01:29+00:00 URL: https://externals.io/message/39525#39532 · In reply to: #39525 Am 01.08.2008 um 12:11 schrieb Antony Dovgal: > 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: 8< > ----- > Total: 22 extensions > > Extensions enabled by default in 5.3: 8< > ------ > Total: 26 extensions 8< Which reminds me I was meaning to ask... Why is ext/xsl not enabled by default? David --- ## #39535 — Antony Dovgal — 2008-08-01T11:33:54+00:00 URL: https://externals.io/message/39525#39535 · In reply to: #39531 > One of the reason of the PHP success is its feature richness. Since when is "feature richness" == "Sqlite3 must be enabled by default"? > ISP, good or bad, enables what we enable. Not true. -- Wbr, Antony Dovgal --- ## #39538 — Antony Dovgal — 2008-08-01T11:53:14+00:00 URL: https://externals.io/message/39525#39538 > It is not about being 100% true or 100% false. We have a couple of > ways to see that, extension usage stastistics and own experiences > (mines in the PEAR time, with htscanner feedbacks on what they use, > and a couple of other things). I provided one source and it reflects > what I said (see nexen.net base configuration stats). Lots of hostings and single servers use default packages from their distributions and distributions tend to include much more than what's enabled by default, so "hostings use what's enabled by default" is just as fake argument as is "hostings are afraid of PECL". Also, even if all of the hosting companies in the world would use simple "./configure", I still couldn't think of a reason to enable ext/sqlite3 by default. -- Wbr, Antony Dovgal --- ## #39541 — Chris Stockton — 2008-08-01T14:34:43+00:00 URL: https://externals.io/message/39525#39541 · In reply to: #39538 The more extensions enabled by default, the more extensions many developers can count on being in common builds. Part of PHP's success is the extension system and the variety of tools it gives the user-base. It is also a nice peace of mind for library developers to be fairly sure the typical php build has X ext. Is their a particular reason you are against giving users such a variety of tools? If performance or binary size I would be interested in stats/benchmarks. I have done some testing in the past when we disabled all extensions we did not use at a previous employer to squeeze some performance out and the benefit was non-existent. -Chris > > > > […] > > Lots of hostings and single servers use default packages from their > distributions and distributions tend to include much more than what's > enabled by default, so > "hostings use what's enabled by default" is just as fake argument as is > "hostings are afraid of PECL". > > Also, even if all of the hosting companies in the world would use simple > "./configure", I still couldn't think of a reason to enable ext/sqlite3 by > default. > > > -- > Wbr, Antony Dovgal --- ## #39542 — Marcus Boerger — 2008-08-01T14:51:28+00:00 URL: https://externals.io/message/39525#39542 · In reply to: #39530 Hello Robert, Friday, August 1, 2008, 12:44:20 PM, you wrote: > Hi folks, > Am 01.08.2008 um 12:30 schrieb Antony Dovgal: > > […] > FWIW: In TYPO3 5.0 we rely on PDO_SQLITE and use it as the default > database directly after the installation of TYPO3. Not because SQLite > is such a performant database, but rather because we can use it > without having to ask the user for any configuration / credentials. > Later on the user has the opportunity to move her data into a more > sophisticated database such as MySQL or Oracle. > So from our point of the universe: Please keep PDO_SQLITE enabled, it > makes our lives much easier. Stuff like this is the exact reason we enabled SQLite by default from the beginning. We discussed it as soon as SQLite was created and all agreed that we should have at least one database always enabled. Now if Type3, one of the largest users of PHP, requires PDO_SQLite, we should definitively enable it by default. And actually my opinion is that there hardly is a reason for an extension to be in core if it is not enabled by default. Best regards, Marcus --- ## #39546 — Ilia Alshanetsky — 2008-08-01T17:28:03+00:00 URL: https://externals.io/message/39525#39546 · In reply to: #39525 I am not sure about SQLite being "always slow", it works rather well in some instances. That said, I agree with the general gist of this e- mail about reviewing closely the extensions that are enabled by default. That said, most people get their PHP from a distributions, which typically make their own decisions about what to include or not. The people who compile by hand for whom this would matter, probably should know what they need or not anyway. > 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), 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). > > -- > Wbr, Antony Dovgal > > -- > > > Ilia Alshanetsky --- ## #39549 — Larry Garfield — 2008-08-02T01:01:19+00:00 URL: https://externals.io/message/39525#39549 · In reply to: #39530 On Friday 01 August 2008 5:44:20 am Robert Lemke wrote: > FWIW: In TYPO3 5.0 we rely on PDO_SQLITE and use it as the default > database directly after the installation of TYPO3. Not because SQLite > is such a performant database, but rather because we can use it > without having to ask the user for any configuration / credentials. > Later on the user has the opportunity to move her data into a more > sophisticated database such as MySQL or Oracle. > > So from our point of the universe: Please keep PDO_SQLITE enabled, it > makes our lives much easier. > > Cheers, > Robert FWIW: Drupal is in the process of moving in the same direction, with our database layer moving over to PDO with intent to ship with a SQLite database for the installer. Having at least that minimum baseline of database capability, however fast or slow it may be, is critical. -- Larry Garfield larry@garfieldtech.com --- ## #39551 — Brian Moon — 2008-08-02T02:50:18+00:00 URL: https://externals.io/message/39525#39551 · In reply to: #39531 Pierre Joye wrote: > ISP, good or bad, enables what we enable. You can see that in the > extension usage statistic (from nexen.net). They have to be taken with > a bit of salt but they represent a good way to see what actually > happens out there. I heard solutions like "educating the ISPs" and > seriously that's a sweet dream and may not reflect their needs. > > An extension not enabled by default is often not used for this exact > reason: it is not enabled by default. So my thoughts are really > simple, unless disable-all is used, enable everything possible as long > as the deps are found (or if there is no dep). As a maintainer of a distributed open source PHP application, I concur with this 1000 fold. If it is not enabled by default, we can not use it in Phorum. We have found that only extensions that the PHP configure includes by default are available on 99% of ISP's servers out there. So, if json is not on by default, for example, we can't use it. -- Brian Moon Senior Web Engineer ------------------------------ When you care enough to spend the very least. http://dealnews.com/ --- ## #39555 — Moriyoshi Koizumi — 2008-08-02T12:37:33+00:00 URL: https://externals.io/message/39525#39555 · In reply to: #39525 Hi, Antony Dovgal wrote: > 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 I don't see any reason to not include mbstring in this list. Moriyoshi --- ## #39556 — Antony Dovgal — 2008-08-02T14:05:10+00:00 URL: https://externals.io/message/39525#39556 · In reply to: #39541 > Is their a particular reason you are against giving users such a variety of > tools? I'm against enabling untested and unmaintained extensions by default, especially if they are known to cause problems. -- Wbr, Antony Dovgal --- ## #39591 — Ilia Alshanetsky — 2008-08-04T02:20:07+00:00 URL: https://externals.io/message/39525#39591 · In reply to: #39556 Perhaps its more of a perception then anything else. If enabled by default simply meant we do so because we can (no external libs needed) rather we think you should have it. There really would be any sort of an issue, and perhaps finally convince people to install what they need rather then delegating the thinking to someone else. Just an idea. > > > […] > > I'm against enabling untested and unmaintained extensions by > default, especially if they are known to cause problems. > > -- > Wbr, Antony Dovgal > > -- > > > Ilia Alshanetsky --- ## #39626 — johannes@php.net — 2008-08-04T11:27:03+00:00 URL: https://externals.io/message/39525#39626 · In reply to: #39525 > 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. I think alpha stage is a time where they can be tested and depending on feedback we can decide how to proceed. I assume most people do a configure and pick their favorite extensions and it's all they test. By enabling we at least compile-test and run-tests.php-test them on multiple platforms. In general I lean towards the "why bundle it if it's not enabled" side. But this is a good discussion and probably I change my opinion on that. johannes --- ## #39637 — Lukas Kahwe Smith — 2008-08-04T17:38:58+00:00 URL: https://externals.io/message/39525#39637 · In reply to: #39527 > > > […] > > I know, I know. > But why enable it by default (as well as PDO_SQLITE)? What's so > extremely useful in this extension that every user needs it? It means that every PHP developer can expect their clients servers to support an SQL backend. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #39872 — Antony Dovgal — 2008-08-12T14:25:37+00:00 URL: https://externals.io/message/39525#39872 · In reply to: #39525 > 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)? See http://bugs.php.net/bug.php?id=45613 for example. Who would have thought that there are multithreaded web-servers, eh? I'm going to disable ext/phar before alpha2. You've been warned. -- Wbr, Antony Dovgal --- ## #39873 — Pierre Joye — 2008-08-12T14:50:50+00:00 URL: https://externals.io/message/39525#39873 · In reply to: #39872 hi, > > > […] > > See http://bugs.php.net/bug.php?id=45613 for example. > Who would have thought that there are multithreaded web-servers, eh? > > I'm going to disable ext/phar before alpha2. > You've been warned. Are you saying that you are going to disable every extension having bugs? That sounds weird, besides that only the RMs has the last word on that. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #39874 — Marcus Boerger — 2008-08-12T14:59:23+00:00 URL: https://externals.io/message/39525#39874 · In reply to: #39872 Hello Antony, Tuesday, August 12, 2008, 4:25:37 PM, you wrote: > > > […] > See http://bugs.php.net/bug.php?id=45613 for example. > Who would have thought that there are multithreaded web-servers, eh? > I'm going to disable ext/phar before alpha2. > You've been warned. Fixed :-) Best regards, Marcus --- ## #39875 — Antony Dovgal — 2008-08-12T15:03:13+00:00 URL: https://externals.io/message/39525#39875 · In reply to: #39873 > > […] > > Are you saying that you are going to disable every extension having > bugs? That sounds weird, besides that only the RMs has the last word > on that. No, I said I'm going to disable new extension that is known to cause obscure problems in the past and that still does cause them at present, and that was (mistakenly) enabled by default right after its creation. And I feel it's now or never, since after alpha2 we'll hear "oh, it's too late to disable it, users now expect it to be enabled". At least that's quite expected after seeing "we enabled it just for alpha" (ha-ha! why don't you enable everything in alpha releases then?). -- Wbr, Antony Dovgal --- ## #39876 — Antony Dovgal — 2008-08-12T15:05:08+00:00 URL: https://externals.io/message/39525#39876 · In reply to: #39874 > > […] > > > […] > > Fixed :-) I'm sorry to say that, but the problem is far more deeper than you thought. No, it still segfaults. -- Wbr, Antony Dovgal --- Next page: https://externals.io/message/39525.md?page=2