On 03/23/2010 10:37 PM, Pierre Joye wrote:
> 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.
No, I suggest to keep sapi/cgi in place and _add_ sapi/fpm as another sapi
module.
This will also ensure that well-tested and mature sapi/cgi will keep being as
it is.
> By the way, how portable is it?
Well, I've already seen a complaint about ARM support missing.
But you're asking about Windows, I guess.
> 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).
No, certainly no Windows testing were done that is known to me.
I'm pretty sure it doesn't even compile there.
And to be honest I doubt there is any need to spend time on it.
> I would suggest to keep it as a separate sapi for now, or forever if it works.
I'd prefer it to stay separate sapi.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
