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" <mike...@gmail.com> wrote in message news:bd9320b30907011117q4fc2c2c3hbffbf289679e6...@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.k...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
