Le 15 avril 2010 13:55, Zeev Suraski <z...@zend.com> a écrit : > At 14:47 15/04/2010, Jérôme Loyet wrote: >> >> > 1. In the .ini parser; That means it'll work for anything that uses >> > the >> > .ini parser, including php.ini, fpm.ini, parse_ini_file(), etc. >> >> It's a huge change, it's has to be tested a lot ... too much complicated= > > Agreed that it's a big change, but it's certainly possible. Requires its > own discussion...
+1 it's totaly out of the scope of this discussion. when I said it's too much complicated, I just meant that it's too much complicated for the need we're trying to discuss here. > >> > 2. In the FPM code that uses the .ini parser; Much like it pays >> > attention >> > to 'daemonize' and 'error_log', it can pay attention to 'include'. >> >> The easiest et most logical solution. FPM wants include in its ini >> configuration file and it's the only part of PHP which need that at >> the moment. Since FPM has been integrated info PHP, it never touched >> something but its own code ... try to stay that way ! > > Is there an inherent reason why include is really necessary for fpm.ini? The reason we want includes is for simplifing fpm configuration file. When you have dozen of pools, the conf file becomes very long and reading/updating it is a pain in the ass. Moreover, there are many directives which are common to all the pools (or group of pools). With includes, you can set those directives once and then, includes all of them at once. There is includes in configuration files for many many server application (apache, nginx, ...). Developping application is one thing, hosting them is another thing which is sometimes forgotten by developpers. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php