Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39560 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84808 invoked from network); 2 Aug 2008 18:58:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2008 18:58:59 -0000 Authentication-Results: pb1.pair.com header.from=jani.taskinen@sci.fi; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=jani.taskinen@sci.fi; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain sci.fi from 63.208.196.178 cause and error) X-PHP-List-Original-Sender: jani.taskinen@sci.fi X-Host-Fingerprint: 63.208.196.178 mho-01-bos.mailhop.org Received: from [63.208.196.178] ([63.208.196.178:50407] helo=mho-01-bos.mailhop.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1A/77-47668-27EA4984 for ; Sat, 02 Aug 2008 14:58:59 -0400 Received: from cs78255253.pp.htv.fi ([62.78.255.253] helo=[127.0.0.1]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KPMJc-000Ivh-4e; Sat, 02 Aug 2008 18:58:56 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 62.78.255.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/YmtZjH6kAYZepTkBf97Cs03Q86FBRsvo= Message-ID: <4894AE70.30805@sci.fi> Date: Sat, 02 Aug 2008 21:58:56 +0300 Reply-To: jani.taskinen@iki.fi User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Derick Rethans CC: Marcus Boerger , PHP Internals List References: <464710978.20080801220313@marcus-boerger.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Another PECL candidate and more extension considerations. From: jani.taskinen@sci.fi (Jani Taskinen) Derick Rethans kirjoitti: > 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. ..which actually doesn't disable that much since some people thought making certain extensions enabled without possibility to disable them was good idea .. --Jani