Re: Bundling "modern" extensions

From: Date: Mon, 06 Jun 2011 15:18:23 +0000
Subject: Re: Bundling "modern" extensions
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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

Thread (74 messages)

« previous php.internals (#53032) next »