Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44599
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.184 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=h2TPSwyRFn4OxSgm0TXN4JV4vvCrP9jnj9v/uWO/3mgaukXXijP90pmIpawh832gAN
         DTXN2nLZGst5VpWtMJvIxo/lK4fkng9EWlvN/7IagMUWkpXBom46DAjPn4MYplKFcfKb
         IOoPUQdZku/NSAUg8NUktZPuTkAlpCKkyK0h4=
MIME-Version: 1.0
In-Reply-To: <A9.0A.24906.978BB4A4@pb1.pair.com>
References: <C9.D2.24906.9A4AB4A4@pb1.pair.com>
	 <bd9320b30907011117q4fc2c2c3hbffbf289679e6b9a@mail.gmail.com>
	 <CE.95.24906.BECAB4A4@pb1.pair.com>
	 <96158496-0C9A-4568-9A74-2D606730D09A@darkrainfall.org>
	 <A9.0A.24906.978BB4A4@pb1.pair.com>
Date: Wed, 1 Jul 2009 12:43:47 -0700
Message-ID: <bd9320b30907011243k1d1bbda8jeca3ecb26b1715ad@mail.gmail.com>
To: Gelu Kelunden <gelu.kelu@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] CGI and FastCGI SAPI
From: mike503@gmail.com (Michael Shadle)

Any way you guys decide to do it, I think taking learnings and/or code
directly from PHP-FPM could be key to base this off of.

One suggestion might be improving the hooks into PHP so that the
process management component can be done separately. This would allow
for distributions to send it as a separate package and the
configuration portion of the FPM can be done in "userland" as opposed
to PHP internally. PHP just needs the hooks into it.

I've already got the following folks in related discussions, which I
believe are the key players in who can help make the decisions on what
to adopt, etc.

Stanislav Malyshev
Dmitry Stogov
Andrei Nigmatulin
Andi Gutmans

Just waiting to have the rubber hit the road and determine the next steps.

Another benefit to adding only the required hooks into PHP core and
keeping FPM in PECL or something else is so that the adaptive process
spawning, angel process creation (which I think would be required for
adaptive monitoring) and other features that never got finished or I'd
like to see implemented could be implemented independent of PHP
development, and PHP core would only need to be patched if something
required a new hook that a PECL/external module or controller could
not handle.

I'd rather see it done in that fashion probably, as waiting for the
next even minor version of PHP for certain FPM features might take a
while, and I have a "wishlist" which I'd like to turn into a "roadmap"
for the FPM functionality, and PHP has a large codebase that can't
move as fast as I'd like for FPM if it was just merged directly in.



On Wed, Jul 1, 2009 at 12:26 PM, Gelu Kelunden<gelu.kelu@gmail.com> wrote:
> Actually I see it a step forward.
>
> In the beginning, the "cgi" SAPI implemented only the CGI protocol. Suppo=
rt
> for FastCGI was added gradually on top of the pure CGI implementation. In
> order to test this "non-stable" code, one would have to use
> "--enable-fastcgi".
>
> Now FastCGI code is stable enough (and also FastCGI got more widespread a=
nd
> now is "the" way to do it) to be built by default. And, as of 5.3.0, you
> cannot build a CGI-only executable anymore.
>
> New features will definately be added to the FastCGI implementation and I
> this it might be good to make the FastCGI SAPI stand-alone and not keep
> arround the CGI-only legacy code.
>
> Gelu
>
>
> "Gwynne Raskind" <gwynne@darkrainfall.org> wrote in message
> news:96158496-0C9A-4568-9A74-2D606730D09A@darkrainfall.org...
>>
>> On Jul 1, 2009, at 2:37 PM, Gelu Kelunden wrote:
>>>
>>> I think that the official FastCGI implementation will eventually =C2=A0=
evolve
>>> into something like PHP-FPM, if not even more.
>>>
>>> What I'm saying is that code that handles daemonization (uid/gid/
>>> chroot/log), workers mgmt (spawing/safe-shutdown), daemon config =C2=A0=
file (not
>>> php.ini or php-cgi.ini) should not be present in the pure =C2=A0CGI SAP=
I
>>> implementation, but in a different FastCGI-only SAPI.
>>
>> This seems to me as if it would be a step backwards. For a long time =C2=
=A0CGI
>> and FastCGI were highly separate setups; you had to use configure =C2=A0=
flags to
>> enable FastCGI, and so forth. In 5.3 they were unified =C2=A0completely:=
 you
>> can't have one without the other anymore. Why would =C2=A0you need to?
>>
>> -- Gwynne
>>
>>> "Michael Shadle" <mike503@gmail.com> wrote in message
>>> news:bd9320b30907011117q4fc2c2c3hbffbf289679e6b9a@mail.gmail.com ...
>>>>
>>>> I think it would be a good idea to also include PHP-FPM in your
>>>> investigation.
>>>>
>>>> On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelunden<gelu.kelu@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to understand how difficult it is to create a new SAPI, =
=C2=A0so
>>>>> I
>>>>> started to poke my nose inside the "cgi" SAPI source code. I saw =C2=
=A0that
>>>>> "cgi_main.c" implements both the CGI and the FastCGI protocols and =
=C2=A0I
>>>>> kinda
>>>>> got lost inside all those if-else lines (I tried to take out the
>>>>> FastCGI
>>>>> code and failed miserably). I'm wondering if it's not better to =C2=
=A0have 2
>>>>> different SAPIs, one for CGI and for FastCGI.
>>>>>
>>>>> Advantages of this "split" would be:
>>>>> - the source code will be more readable without all those if-else
>>>>> statements
>>>>> - we would have 2 executables that do 2 different jobs, unlike now
>>>>> where
>>>>> php-cgi does both; each executable could then be further optimized =
=C2=A0for
>>>>> the
>>>>> exact job they are performing
>>>>>
>>>>> Disadvantages I see:
>>>>> - maintaning 2 SAPI implementaion would require more work (since =C2=
=A0CGI
>>>>> and
>>>>> FastCGI both share most of the SAPI code, any change would have to =
=C2=A0be
>>>>> replicated twice)
>>>>> - break backward compatibility (where php-cgi handles both CGI and
>>>>> FastCGI)
>>>>>
>>>>> Thank you for your time,
>>>>> Gelu
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>