Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52915
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=Lg2in4dY1MP15ixlooJwBtCS5RFZEIUd3nru3CfAFunq/CIuL0FGk32k6RaiKEelZR
         4WAAmDyFARFx06EdVq+W3nvdPCxaTdVNNXpP2h03ybXwySfbfRsCnJe7sDhqo8oPFy2S
         /FEcX4H6fgYbyHJuOpsYGVvKnjyeSIh0pV428=
MIME-Version: 1.0
In-Reply-To: <8757232E56758B42B2EE4F9D2CA019C901499F97@US-EX2.zend.net>
References: <8757232E56758B42B2EE4F9D2CA019C901499F97@US-EX2.zend.net>
Date: Sun, 5 Jun 2011 12:57:55 +0200
Message-ID: <BANLkTikau4c4-HzkGAXG15AMS2tr6fe+NA@mail.gmail.com>
To: Andi Gutmans <andi@zend.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Bundling "modern" extensions
From: pierre.php@gmail.com (Pierre Joye)

hi,

It sounds like persons doing these inquiries do not know PHP, its
environment and how it works, neither they know that 99% of the linux
distribution (and in some extend on windows too)  provide most of the
modern extensions with their standard distribution.

For general purposes extensions or really globally useful (as any
almost all php users will have a use), like pecl's http, I'm all for
having them in the core. In the case of http it was even already
proposed and somehow rejected. If Mike feels like it is time again to
propose it, then let him do it. oAuth2 or yaml may be bundled but I'm
not a fan of getting those in tbh.

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.

My reasoning is simple. The key for bundling extensions is to have
them available for most hosting solutions. If a shared host provides
support for mongodb, then he will most likely enable the mongodb
extension in php, if he knows what he is doing. The same applies for
all other non core critical features but more from an architecture
point of view.

It will be also hardly possible to begin to bundle all nosql/cache
extensions in the core without creating a maintenance nightmare. I
don't want to imagine the QA checks for the core if we begin to have
them in core. No, I really don't want.

The last point is that pecl allows a much more flexible release
management than the core will even do. So instead of doing some
marketing/communication actions by bundling some known extensions, we
should better promote pecl better. Improve the website (ping me if you
like to help) by supporting non svn repository like github&co, etc.
etc.

Cheers,

On Sun, Jun 5, 2011 at 1:00 AM, Andi Gutmans <andi@zend.com> wrote:
> Hi,
>
> I've been getting quite a few inquiries re: PHP's "lack" of support for m=
odern technologies such as NoSQL databases (for lack of better term). There=
 is some (mistaken) perception that PHP is behind on this front.
>
> I think one of the problems is that in the past we always ensured that th=
e extensions for key current technologies were bundled with PHP i.e. mysql,=
 json & soap/xml. This was one of our biggest strengths and advantages and =
it would propagate to Linux distros, shared hosting, etc.. Therefore, I thi=
nk we should move towards bundling some of the key extensions to ensure the=
y are easily found by people esp. when people are getting them via third pa=
rties.
>
> For starters I would bundle ext/mongo which is very well maintained; see =
if we can get "thrift_protocol" contributed to PECL and included (support H=
Base and Cassdandra and used by a few PHP SDKs integrating with these data =
stores).
>
> In parallel I'd also see if there are any key extensions which we think a=
re mainstream, stable and well maintained enough to be included. For exampl=
e, http comes to mind.
>
> Anyway, I am not suggesting we go and include a lot more but I think ther=
e are a few key ones, and I would start with very strong NoSQL support exte=
nsions that already exist to ensure the eco-system picks them up and we mak=
e them readily available + get rid of any false perceptions that exist.
>
> Andi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org