Actually I see it a step forward.
In the beginning, the "cgi" SAPI implemented only the CGI protocol. Support
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 and
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" <gwy...@darkrainfall.org> wrote in message
news:96158496-0c9a-4568-9a74-2d606730d...@darkrainfall.org...
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
