Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39554 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70770 invoked from network); 2 Aug 2008 09:40:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2008 09:40:11 -0000 Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.94.239.7 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.94.239.7 mail.jdi-ict.nl Linux 2.6 Received: from [82.94.239.7] ([82.94.239.7:38744] helo=mail.jdi-ict.nl) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 36/59-39007-97B24984 for ; Sat, 02 Aug 2008 05:40:11 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.jdi-ict.nl (8.13.7/8.12.11) with ESMTP id m729e5OR009733; Sat, 2 Aug 2008 11:40:05 +0200 Date: Sat, 2 Aug 2008 11:40:06 +0200 (CEST) X-X-Sender: derick@kossu.ez.no To: Marcus Boerger cc: PHP Internals List , =?UTF-8?Q?Johannes_Schl=C3=BCter?= , Lukas Kahwe Smith In-Reply-To: <464710978.20080801220313@marcus-boerger.de> Message-ID: References: <464710978.20080801220313@marcus-boerger.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Subject: Re: [PHP-DEV] Another PECL candidate and more extension considerations. From: derick@php.net (Derick Rethans) On Fri, 1 Aug 2008, Marcus Boerger wrote: > 2) We might not really be ready for one and continue doing as we've always > done. Select a nice collection of extension that aims to make the majority > of our userbase happy. And suggest defaults this way whether or not they > are enabled by default. The default enabled exts are just a stronger > suggesttion that we think people should be able to rely on. Yes, having a good feature rich PHP core is important. If an extension is not enabled by default, implementers of public-ready applications can't rely on it. Saying that it is "bloat" if more things are enabled by default isn't really an argument - because the people for whom that really matters, can very easily use --disable-all. regards, Derick