Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52931
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
DomainKey-Status: bad
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=ZTqRprOXWKG7cusPmpQoqyqsKozJOg/xkFECQ/1Vrnf7ACuEPDYJuOVzw/0+K8Y5H8
         AfgVy7T0fw1Hcx9qSwIBTfmY+WYWTKnMAR8g0hrC4u1+nRqxbOltbeH7yewuf1q0+/hm
         A/DjLgR29wrW1BArtcfI5F6oNjuz2mQHsvE10=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <BANLkTikp1gS2nptJ_7v5941Y-MK1HcvgtA@mail.gmail.com>
References: <8757232E56758B42B2EE4F9D2CA019C901499F97@US-EX2.zend.net>
	<BANLkTikau4c4-HzkGAXG15AMS2tr6fe+NA@mail.gmail.com>
	<BANLkTikp1gS2nptJ_7v5941Y-MK1HcvgtA@mail.gmail.com>
Date: Sun, 5 Jun 2011 14:54:20 +0200
Message-ID: <BANLkTinDvYLwt5y4df5erNxL1Y=N2Jtv+g@mail.gmail.com>
To: Hannes Magnusson <hannes.magnusson@gmail.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Andi Gutmans <andi@zend.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf301fb9054a045f04a4f67cb8
Subject: Re: [PHP-DEV] Bundling "modern" extensions
From: info@tyrael.hu (Ferenc Kovacs)

--20cf301fb9054a045f04a4f67cb8
Content-Type: text/plain; charset=UTF-8

On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson <hannes.magnusson@gmail.com
> wrote:

> On Sun, Jun 5, 2011 at 12:57, Pierre Joye <pierre.php@gmail.com> wrote:
> > However, for technologies specific extension, be hyped or not, I see
> > no reason to bundle them. It makes no sense to bundle mongodb,
> > memcached clients or whatever other specific features.
>
> I can't think of a statement I would disagree more with. These are
> exactly the ones we should be bundling.
>
>
> > My reasoning is simple. The key for bundling extensions is to have
> > them available for most hosting solutions. If a shared host provides
>
>
> No. Join the real world again. Anything not in vanilla PHP is hard to
> install because it causes more work in maintenance of the server, and
> increases the risk of fuckups etc etc
>
> Being able to use "hyped technology" out-of-the box is exactly what we
> want to achieve.
>
> -Hannes
>
>
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.

the other group, now they usually use and need such stuff, but they are
willing and able to install the necessary extensions.

btw. my biggest problem with "bleeding edge" technologies like redis,
mongodb or memcache(and they aren't that new or bleeding edge...) is not the
fact that they aren't in the core, but that we lack good php extensions to
interact with them.
for example we have two concurent lib for memcached, both have their cons
and pros, for redis afaik the best implementation and actively maintened lib
is rediska, we don't have anything for redis in pear/pecl, for mongodb at
least we ?have? a feature complete implementation.

so I think that providing/improving those would be a better idea than
including what we currently have for marketing purposes.

Tyrael

--20cf301fb9054a045f04a4f67cb8--