2010/4/15 Derick Rethans <der...@php.net> > On Tue, 13 Apr 2010, Zeev Suraski wrote: > > > At 21:46 13/04/2010, Christopher Jones wrote: > > > > > Jérôme Loyet wrote: > > > > Le 13 avril 2010 20:17, Christopher Jones > > > > <christopher.jo...@oracle.com> a écrit : > > > > > > > > > > Jérôme Loyet wrote: > > > > > > > > > > > > As dreamcast4 advises me in the previous FPM conversation, I > > > > > > just wrote the RFC for the FPM INI syntax. > > > > > > > > > > > > It can be read here: http://wiki.php.net/rfc/fpm/ini_syntax > > > > > > > > > > > > Tell me what you think. > > > > > > > > > > > I think the RFC should clearly state what is new generic php.ini > > > > > functionality (e.g. include) and what is specific for FPM. > > > > > > > > for me everything is specific to FPM > > > > > > How is "include" specific to FPM? > > > > What he means is that it'll be implemented in the custom code > > responsible for parsing fpm.ini, and not in the ZE .ini parser which > > would be the layer below it. > > Uh, so what you're saying is that you want to use INI syntax for FPM so > that it is inline with php's INI sytanx, but then modify it with extra > statements so that it isn't the same anymore—not only with include, but > section headers are totally ignored in php.ini as well. This whole new > INI thing is making less and less sense. The XML format like we have now > is much easier, self documented, doesn't create two different ini > formats and generally just works well. I'd be a big -1 on this special > FPM-specific INI syntax. > > Derick > > Agree, I thought that the include part will be handled from the application. I mean you parse the global config, read the include param, and read each of the matching ini for merging them to the original config format.
Tyrael
