2010/3/23 Pierre Joye <pierre....@gmail.com>:
> hi Tony,
>
> On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal <t...@daylessday.org> wrote:
>
>>> Does it really need to be separate SAPI? I mean, just replace the old
>>> sapi/cgi
>>> with it? Keep the name 'cgi' though. :)
>>
>> I don't see any need to touch sapi/cgi at all.
>> Keeping both CGI and FastCGI in one SAPI leads to a nasty code mess with
>> lots of
>> "if (fcgi_is_fastcgi()) {" as you can now see in cgi_main.c.
>
> Not sure to follow, are you suggesting to consider FPM as the
> sapi/cgi's fastcgi replacement? As Jani is suggesting.
>
>> sapi/fpm and sapi/cgi now have quite different codebase as we've dropped
>> some stuff
>> not pertinent to FastCGI (there might be some leftovers, I'll deal with them
>> later).
>
> By the way, how portable is it? I don't think it has been tested on
> windows (some of the key features are not necessary with IIS/FCGI as
> they do it already but could be for other web servers).
As far as I know, It's not been tested on windows. It depends on
libevent which is available for windows, so porting fpm to windows
should not be a big deal (technicaly I mean, it'll maybe take some
time). I'm not a windows dev specialist, I'm maybe missing a point
somewhere.
>
> I would suggest to keep it as a separate sapi for now, or forever if it works.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> 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
