On Wed, 24 Mar 2010, Zeev Suraski wrote:
> At 00:01 24/03/2010, Derick Rethans wrote:
> > I don't see how this actually matters. None of the other SAPIs are
> > configured with a php.ini syntax.
>
> None of the other SAPIs are configured, period.
That's not true. You configure the fastcgi SAPI for lighttpd in the
lighttpd config, in LUA. Sure, it's the web-server side of it, but it's
no different from sapi/fpm which is its own little wrapper instead of
the one that comes with lighttpd.
## Start an FastCGI server for php
fastcgi.server = ( ".php" =>
((
"bin-path" => "/usr/local/php/5.3dev/bin/php-cgi",
"socket" => "/tmp/php80.socket",
"max-procs" => 1,
"idle-timeout" => 20,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "1",
"PHP_FCGI_MAX_REQUESTS" => "10000"
),
"bin-copy-environment" => (
"PATH", "SHELL", "USER"
),
"broken-scriptfilename" => "enable"
))
)
This is in no way different than doing the configuration for the FPM
sapi in their XML file.
> This SAPI requires much more configuration - and I agree it's equivalent to
> web server configuration - but given that it's going to be bundled in PHP, it
> should use the same syntax.
>
> > That includes IIS, Apache, Lighttpd
> > and others. This is more of a webserver thing than a "PHP thing" so I
> > don't see how it is relevant to require php.ini syntax if this XML
> > configure file works just fine already. I mean, it'd be *nice* to have a
> > non-XML syntax, but for me this is definitely not a requirement for FPM
> > to be added to trunk. If you (or somebody else) wants a php.ini syntax
> > for it, a patch can be written. It's Open Source after all.
>
> For me it is a requirement before the code makes it into a released
> version of PHP
We're not nearly close to a release.
> , and I think many others think that way if past discussions are any
> indication. That's what RFCs are for - if people can just go ahead and
> implement their original thoughts without paying attention to feedback, why
> bother?
> Personally I think that the person pushing the code should be responsible for
> implementing the feedback to the RFC (or getting others to do it).
But I don't think they should just blatently pick up on any suggestion
that comes in through the mailinglist. Feedback is good, but that
doesn't mean all of it should be taken into account in the code before
you even allow it to be in. And feedback can also come in patches if you
really find it so important to have a .ini syntax.
My take on this is:
- Add sapi/fpm to trunk; it's standalone, it works
- If somebody finds it necessary, write the code for it and we can
discuss whether we actually want a .ini file like syntax.
with kind regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
