Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44594
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain darkrainfall.org from 208.97.132.74 cause and error)
To: "Gelu Kelunden" <gelu.kelu@gmail.com>
In-Reply-To: <CE.95.24906.BECAB4A4@pb1.pair.com>
References: <C9.D2.24906.9A4AB4A4@pb1.pair.com> <bd9320b30907011117q4fc2c2c3hbffbf289679e6b9a@mail.gmail.com> <CE.95.24906.BECAB4A4@pb1.pair.com>
Message-ID: <96158496-0C9A-4568-9A74-2D606730D09A@darkrainfall.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 1 Jul 2009 14:58:12 -0400
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] CGI and FastCGI SAPI
From: gwynne@darkrainfall.org (Gwynne Raskind)

On Jul 1, 2009, at 2:37 PM, Gelu Kelunden wrote:
> I think that the official FastCGI implementation will eventually  
> 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  
> file (not php.ini or php-cgi.ini) should not be present in the pure  
> CGI SAPI implementation, but in a different FastCGI-only SAPI.

This seems to me as if it would be a step backwards. For a long time  
CGI and FastCGI were highly separate setups; you had to use configure  
flags to enable FastCGI, and so forth. In 5.3 they were unified  
completely: you can't have one without the other anymore. Why would  
you 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,  
>>> so I
>>> started to poke my nose inside the "cgi" SAPI source code. I saw  
>>> that
>>> "cgi_main.c" implements both the CGI and the FastCGI protocols and  
>>> I 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  
>>> have 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  
>>> for the
>>> exact job they are performing
>>>
>>> Disadvantages I see:
>>> - maintaning 2 SAPI implementaion would require more work (since  
>>> CGI and
>>> FastCGI both share most of the SAPI code, any change would have to  
>>> be
>>> replicated twice)
>>> - break backward compatibility (where php-cgi handles both CGI and  
>>> FastCGI)
>>>
>>> Thank you for your time,
>>> Gelu