Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53033 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88191 invoked from network); 6 Jun 2011 15:38:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jun 2011 15:38:05 -0000 Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-ww0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:35785] helo=mail-ww0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CA/82-06642-B54FCED4 for ; Mon, 06 Jun 2011 11:38:04 -0400 Received: by wwd20 with SMTP id 20so3641083wwd.11 for ; Mon, 06 Jun 2011 08:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hoX2C7qYWFr/qpELQx5teFJN9DbY23ogQvrqNA63bac=; b=Qw8lUVnk30Ma8J/za976Enr2699B6wqW2ma4e96bIV6+5e6p0cKWscrYmx0+i2r+ek bdt4llxLDEX8N1LQUJ2QS7p3f5haLMygUGPxLEsqT1OXZlNTHKNz95EEy7j3/QyxbuF3 SU8RzWsOgO70OpoWfKLP09pZGT+v/mbSDzrAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Qow+x37T+lceZMjqIg4rhxuhTVkqeYAkenRii5bctcpNJFlYQ54C+VNEysNbIEJNuw PHtJRvLniJ8oXKjvIiYCYB4rf4PElJhnW5UBq49dbZRhNmzIokoZp/k01jpUuaCILnap cno8y05gphqG4PIvMg601LPKrn2hBmqdyNQDM= MIME-Version: 1.0 Received: by 10.216.235.22 with SMTP id t22mr2580358weq.89.1307374680244; Mon, 06 Jun 2011 08:38:00 -0700 (PDT) Sender: tyra3l@gmail.com Received: by 10.216.64.6 with HTTP; Mon, 6 Jun 2011 08:38:00 -0700 (PDT) In-Reply-To: <4DECEFBF.5070105@garfieldtech.com> References: <8757232E56758B42B2EE4F9D2CA019C901499F97@US-EX2.zend.net> <4DECEFBF.5070105@garfieldtech.com> Date: Mon, 6 Jun 2011 17:38:00 +0200 X-Google-Sender-Auth: TTSIchLhgWEge9c8pcQ7OP7QedE Message-ID: To: Larry Garfield Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=000e0ce03ed067833604a50ce379 Subject: Re: [PHP-DEV] Bundling "modern" extensions From: info@tyrael.hu (Ferenc Kovacs) --000e0ce03ed067833604a50ce379 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield wrote: > On 6/5/11 7:54 AM, Ferenc Kovacs wrote: > > just for the record, I agree with Pierre on this one. >> our userbase has two distinct group: those who are using shared hosting >> and >> usually use some third party cms or write their own crappy suboptimal >> code, >> and those who use php to build bleeding edge custom product (either on top >> of some 3rd party framework, or on their own). >> for the first group, they doesn't configure their installation, but their >> hosting providers do that for them. >> those providers usually has custom configuration or compilation of php, >> because by default, there are many ways where one user in the shared >> environment can blow up or compromise the full server. >> so for those people, including more stuff in the core means change, which >> they have to adapt, and migrate (add more disable_ to the vhost configs or >> recompile php without the newly included stuff). >> btw. usually the general cms solutions targets the standard installations, >> so they won't use stuff like mongodb. at least not as a requirement in >> their >> core functionalities. >> > > As someone who deals mostly with managed hosting (not necessarily "shared" > but a server where the customer doesn't have root), that's an important > consideration. For anyone working in the non-custom CMS world (Drupal, WP, > Joomla, etc.), knowing the baseline you can expect from a general PHP host > is critically important. Drupal, for instance, considered but rejected > making SQLite a requirement for Drupal 7 for some low-level bootstrapping > logic because we found a few hosts that we did want to continue to support > that didn't bundle it. > > The only way, currently, that projects can predict what a given host will > have installed is "bundled in core PHP". If it's in the core PHP bundle, we > can *usually* expect it to be there. If not, we can *usually* presume it > won't be. That's not a hard and fast rule, but it's the best we've got > right now. > > For me the question isn't "should we bundle memcached in PHP core", it's > "how do we establish an expected baseline of PHP components that developers > can reasonably expect will be available, and what should be in that?" Right > now, that baseline is "bundled in core". > > This question is completely irrelevant to people who always have root on > their dev and production servers, but they are, frankly, a minority of > PHP-using domains out there. For those who deal in the mass-market, knowing > that baseline is critical. > > So how do we establish that baseline if not by bundling an extension in > core? > > the "in core" can mean different things. as I mentioned before, the distributors package the php stuff on their own way. so for example debian packages curl, gd, imap, intl, ldap, mysql separately when we have this in "core", and they also have common pecl modules as php packages. event stuff like mysql isn't enabled by default for example, obviously almost every hosting provider will install that. Tyrael --000e0ce03ed067833604a50ce379--