On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield <la...@garfieldtech.com>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
