Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53032
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <4DECEFBF.5070105@garfieldtech.com>
Date: Mon, 06 Jun 2011 10:18:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: internals@lists.php.net
References: <8757232E56758B42B2EE4F9D2CA019C901499F97@US-EX2.zend.net>	<BANLkTikau4c4-HzkGAXG15AMS2tr6fe+NA@mail.gmail.com>	<BANLkTikp1gS2nptJ_7v5941Y-MK1HcvgtA@mail.gmail.com> <BANLkTinDvYLwt5y4df5erNxL1Y=N2Jtv+g@mail.gmail.com>
In-Reply-To: <BANLkTinDvYLwt5y4df5erNxL1Y=N2Jtv+g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Bundling "modern" extensions
From: larry@garfieldtech.com (Larry Garfield)

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?

--Larry Garfield