Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44484
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.221.198 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;
        b=OcfLi/ygFqmmP3nTXnA+ciZ1HDSGQH0ulWVT1y0DDEs+ZD2xZfItvNiXHZONaq6HYT
         RzY85jt7Z5DnDjJIvUn8tDlk/3QFZf9SXpi1ZOPOUkuYOTOy5xojXqiuM5vDnlXoX4i4
         kgaEtsSGg6sojM5AAwNKULSw9Z9BfeQeyI7WA=
MIME-Version: 1.0
In-Reply-To: <4A451E00.4090409@zend.com>
References: <bd9320b30906261147qea889a0j4fb5730846e729f2@mail.gmail.com>
	 <4A451E00.4090409@zend.com>
Date: Fri, 26 Jun 2009 12:30:54 -0700
Message-ID: <bd9320b30906261230p22ce671bm4b659494d251931b@mail.gmail.com>
To: Stanislav Malyshev <stas@zend.com>
Cc: PHP Development <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e64eabf406951b046d45611c
Subject: Re: [PHP-DEV] PHP-FPM is now BSD-compatible, I believe there was 
	interest in integrating it/portions of it into PHP core?
From: mike503@gmail.com (Michael Shadle)

--0016e64eabf406951b046d45611c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On Fri, Jun 26, 2009 at 12:14 PM, Stanislav Malyshev <stas@zend.com> wrote:

> Hi!
>
>  It would be great if someone would examine the impact of adopting it
>> as the FastCGI SAPI replacement or looking at what hooks are required
>> to get it in and perhaps keep the "userland" stuff in PECL...
>>
>
> Why it needs to replace existing fcgi SAPI? I would think it is better to
> have it just as another SAPI - isn't it possible? I understand (please
> correct me if I'm wrong) that php-fpm feature set is different from what
> fcgi SAPI now does - php-fpm manages its own processes, etc. which may be
> not what some FCGI drivers expect.
>
> I think it is possible to add it as SAPI for HEAD at any time, and once 5.3
> is out of the release freeze, add it to 5.3 as well.
> --
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com
>

I would be more than happy if you would like to do that!
I believe that Dmitry was interested in actually *replacing* the FastCGI
SAPI with it (or at least patching it 100%) - the configuration options and
"userland" usage of it is where I am not sure how it would "bundle" with PHP
properly. It uses a different config syntax (not ini compatible)

There's 4 options I see:

1) Merge it 100% into PHP core (I see some issues with how to configure it
then)
2) Merge all the core changes required for it to work as a PECL module (so
people can use it via PECL if they wish and configure it how they want, and
all config file syntax changes and such can be done inside of PECL)
3) Make it 100% PECL (don't think this is possible as it needs too many
things inside of the core of PHP to be changed)
4) Keep it as a patch (lower adoption, current status quo)

Option #2 might be the best. That will allow for PECL to continue to advance
feature-wise without having to change PHP core. I have a wishlist of ideas
to be implemented and it will be harder if the patch is 100% merged into
PHP.

However, PHP itself does need a handful of things from the patch for PHP-FPM
to work properly. I believe that PHP-FPM can easily be added to the existing
FastCGI SAPI and provide a few extra additions into it, without changing the
existing FastCGI SAPI's behavior. But the hooks need to be put into place so
the PECL module can take advantage of it.

I will help facilitate whatever needs to get done to make this happen.
Anyone who would like to examine it feel free to grab the 5.2.10 patch and
examine it. There hasn't been one produced for 5.3.0 since a much earlier
cvs snapshot, so I would ignore that one.

Taking what is required out of 5.2.10 and baking it in to PHP and then
helping get a PECL module going would probably be the best route to go,
assuming a PECL module can do things such as terminate errant requests based
on configuration options, launch php-cgi processes (essentially), being
started from root, etc.

If funds are required, feel free to shoot me a number. I will try to drum up
what is required to push this through.

This is my wishlist (which in turn would be great to turn in to a roadmap,
just so you know)
http://php-fpm.org/Wishlist

Having some sort of reporting mechanism would be great. The fastcgi.txt file
I reference as well was a rough idea I came up with before knowing about
PHP-FPM, and some of the threshhold warning messages and such would be great
to have too.

--0016e64eabf406951b046d45611c--