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