On Tue, Mar 23, 2010 at 10:16 PM, Zeev Suraski <z...@zend.com> 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; The little configuration > they do have is done using php.ini. > 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.
Maybe its valid to make an exception for FPM, given that it has an exceptional number of configuration options. I would ask, how easy is PHP.ini to debug? One great thing about the nginx configuration parser is that it gives decent error messages when you've got the config all wrong. But in any case I dont believe you should require Antony to implement this if its out of his area of expertise, and there are plenty of other people around who can contribute the code better / more enthusiastically. >> 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, 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). > > Zeev > > > > -- > 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
