Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39546 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35062 invoked from network); 1 Aug 2008 17:28:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Aug 2008 17:28:09 -0000 Authentication-Results: pb1.pair.com header.from=ilia@prohost.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ilia@prohost.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain prohost.org from 64.233.166.179 cause and error) X-PHP-List-Original-Sender: ilia@prohost.org X-Host-Fingerprint: 64.233.166.179 py-out-1112.google.com Received: from [64.233.166.179] ([64.233.166.179:24482] helo=py-out-1112.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 72/92-39007-8A743984 for ; Fri, 01 Aug 2008 13:28:09 -0400 Received: by py-out-1112.google.com with SMTP id a25so499046pyi.16 for ; Fri, 01 Aug 2008 10:28:06 -0700 (PDT) Received: by 10.64.185.18 with SMTP id i18mr929701qbf.85.1217611686048; Fri, 01 Aug 2008 10:28:06 -0700 (PDT) Received: from ?192.168.1.129? ( [76.65.228.201]) by mx.google.com with ESMTPS id k8sm3022066qba.5.2008.08.01.10.28.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 Aug 2008 10:28:05 -0700 (PDT) Cc: php-dev Message-ID: <969C33A7-1C94-4134-AB54-D27FF9CD73D9@prohost.org> To: Antony Dovgal In-Reply-To: <4892E15D.1080004@daylessday.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 1 Aug 2008 13:28:03 -0400 References: <4892E15D.1080004@daylessday.org> X-Mailer: Apple Mail (2.926) Subject: Re: [PHP-DEV] enabling everything by default From: ilia@prohost.org (Ilia Alshanetsky) 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. On 1-Aug-08, at 6:11 AM, 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), 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Ilia Alshanetsky