# [RFC] FPM INI syntax - Thread: https://externals.io/message/47684 - Original archive: https://news-web.php.net/php.internals/47684 - Started by jerome@loyet.net on 2010-03-30T17:08:33+00:00 - Messages: 31 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/47684.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #47684 — jerome@loyet.net — 2010-03-30T17:08:33+00:00 URL: https://externals.io/message/47684#47684 Hi guys, 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. ++ Jerome --- ## #47882 — Derick Rethans — 2010-04-12T08:39:59+00:00 URL: https://externals.io/message/47684#47882 · In reply to: #47684 > 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. That seems to be extremely complicated. I definitely prefer the existing XML form. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47887 — dreamcat four — 2010-04-12T11:47:51+00:00 URL: https://externals.io/message/47684#47887 · In reply to: #47882 2010/4/12 Derick Rethans : > > > > […] > > That seems to be extremely complicated. I definitely prefer the existing > XML form. Derek, Make sure youve also taken a look at Jerome's mockup / example files. They were posted in the other thread, so I shall post them again here. INI > http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html XML > http://www.fatbsd.com/fpm/xml.html Perhaps those links could do with being added to the RFC page too. Jerome? > > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug --- ## #47904 — jerome@loyet.net — 2010-04-13T09:19:15+00:00 URL: https://externals.io/message/47684#47904 · In reply to: #47887 Le 12 avril 2010 13:47, dreamcat four a écrit : > 2010/4/12 Derick Rethans : > > […] > > Derek, > Make sure youve also taken a look at Jerome's mockup / example files. > They were posted in the other thread, so I shall post them again here. > > INI > > […] > > XML > > […] > > Perhaps those links could do with being added to the RFC page too. Jerome? done. To compare really: http://www.fatbsd.com/fpm/xml.html http://www.fatbsd.com/fpm/fpm_ini.html I made some small changes and update to RFC version 1.1 ++ Jerome --- ## #47905 — Ferenc Kovacs — 2010-04-13T09:33:57+00:00 URL: https://externals.io/message/47684#47905 · In reply to: #47904 > done. > To compare really: > http://www.fatbsd.com/fpm/xml.html > http://www.fatbsd.com/fpm/fpm_ini.html > > I made some small changes and update to RFC version 1.1 > ++ Jerome > > -- > > > > There is a little typo in the fmp_ini.html: /etc/fpm/bacloffice.conf should be /etc/fpm/backoffice.confTyrael --- ## #47906 — jerome@loyet.net — 2010-04-13T09:35:53+00:00 URL: https://externals.io/message/47684#47906 · In reply to: #47905 Le 13 avril 2010 11:33, Ferenc Kovacs a écrit : > > > […] > > There is a little typo in the fmp_ini.html: > > /etc/fpm/bacloffice.conf > > should be > > /etc/fpm/backoffice.conf > corrected, thx Tyrael --- ## #47902 — Zeev Suraski — 2010-04-13T10:14:00+00:00 URL: https://externals.io/message/47684#47902 · In reply to: #47684 At 20:08 30/03/2010, Jérôme Loyet wrote: >Hi guys, > >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. Looks good to me. Zeev --- ## #47908 — Arvids Godjuks — 2010-04-13T10:51:41+00:00 URL: https://externals.io/message/47684#47908 · In reply to: #47906 Hello. Here is some userland feedback: I was following the thread closely, because I use fastcgi all the time. I can now say for sure, that you did really good job with ini syntax - the one you have at the moment looks and feels just perfect. And includes make it really easy to use - it's what XML syntax lacks. Please roll that out as soon as possible, i'd like to get my hands on that in stable release to use :) --- ## #47920 — jerome@loyet.net — 2010-04-13T18:42:06+00:00 URL: https://externals.io/message/47684#47920 Le 13 avril 2010 20:17, Christopher Jones a écrit : > > > Jérôme Loyet wrote: > > […] > > 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 > Also, if "globals" is specific to FPM then it should not use such > a generic term.  It should be "fpm_globals" or similar. This RFC describe the FPM configuration file syntax. The FPM configuration file is totaly independant from php.ini (%prefix%/etc/php-fpm.conf) > > The "is_a_reference" & "reference" stuff seems overly complex. maybe, it's an idea. > > Chris > > -- > Email: christopher.jones@oracle.com > Tel:  +1 650 506 8630 > Blog:  http://blogs.oracle.com/opal/ > Free PHP Book: http://tinyurl.com/ugpomhome --- ## #47923 — Zeev Suraski — 2010-04-13T19:01:21+00:00 URL: https://externals.io/message/47684#47923 At 21:46 13/04/2010, Christopher Jones wrote: >Jérôme Loyet wrote: > > […] > >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. Implementing include() can be done at either layer. If it's implemented at the bottom layer (ZE) then it'll transparently effect any and all .ini's - not sure we want that (maybe). If we implement it at the top layer - the custom code that's responsible for fpm.ini, then it will be entirely specific to it and won't effect php.ini behavior in any way (exactly like the support for the 'extension' keyword is implemented for php.ini, but not for any other .ini's - because it's at the top custom-code layer). Zeev --- ## #47924 — Michael Shadle — 2010-04-13T19:10:22+00:00 URL: https://externals.io/message/47684#47924 · In reply to: #47923 2010/4/13 Zeev Suraski : > 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.  Implementing include() can be done at either layer.  If it's > implemented at the bottom layer (ZE) then it'll transparently effect any and > all .ini's - not sure we want that (maybe).  If we implement it at the top > layer - the custom code that's responsible for fpm.ini, then it will be > entirely specific to it and won't effect php.ini behavior in any way > (exactly like the support for the 'extension' keyword is implemented for > php.ini, but not for any other .ini's - because it's at the top custom-code > layer). I think generic include capability for php .ini files would be quite handy. --- ## #47925 — jerome@loyet.net — 2010-04-13T19:34:08+00:00 URL: https://externals.io/message/47684#47925 · In reply to: #47923 Le 13 avril 2010 21:01, Zeev Suraski a écrit : > At 21:46 13/04/2010, Christopher Jones wrote: > > > > […] > > 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.  Implementing include() can be done at either layer.  If it's > implemented at the bottom layer (ZE) then it'll transparently effect any and > all .ini's - not sure we want that (maybe).  If we implement it at the top > layer - the custom code that's responsible for fpm.ini, then it will be > entirely specific to it and won't effect php.ini behavior in any way > (exactly like the support for the 'extension' keyword is implemented for > php.ini, but not for any other .ini's - because it's at the top custom-code > layer). > Thanks Zeev for translating my thought :) --- ## #47963 — jerome@loyet.net — 2010-04-15T10:09:55+00:00 URL: https://externals.io/message/47684#47963 · In reply to: #47684 hi I made the first release of the patch to convert fpm syntax from xml to ini. Everything is in the RFC: http://wiki.php.net/rfc/fpm/ini_syntax The patch is directly viewable at the following address: http://www.fatbsd.com/fpm/fpm-ini-v1.patch This patch does not make everything described in the RFC: - the include directive is not yet implemented because the zend_ini_parser is not able to handle recursive calls (because of the the state env which is global) - the reference system which is complex and I'm not sure it's a good idea everything else has been done and I'm working now on implementing includes. As it's a huge patch, I won't commit it directly so if some of you can make comments it would be great. thx guys ++ Jerome Le 30 mars 2010 19:08, Jérôme Loyet a écrit : > Hi guys, > > 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. > > ++ Jerome --- ## #47964 — Derick Rethans — 2010-04-15T10:56:12+00:00 URL: https://externals.io/message/47684#47964 · In reply to: #47923 > At 21:46 13/04/2010, Christopher Jones wrote: > > > […] > > 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 -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47969 — Zeev Suraski — 2010-04-15T11:11:09+00:00 URL: https://externals.io/message/47684#47969 · In reply to: #47964 At 13:56 15/04/2010, Derick Rethans wrote: >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. Derick, You're confusing syntax and semantics. The syntax is very much .ini, it's identical to php.ini's syntax. The semantics is designed to fit the needs of FPM. If you follow my emails on this topic you'd see that this is what I was pushing all along, nothing new here. It's much like the syntax of the current config file is XML - but we could implement the semantics in dozens of different ways. > 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 completely disagree. Zeev --- ## #47970 — Ferenc Kovacs — 2010-04-15T11:12:03+00:00 URL: https://externals.io/message/47684#47970 · In reply to: #47964 2010/4/15 Derick Rethans > > > > […] > > 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 --- ## #47972 — Zeev Suraski — 2010-04-15T11:17:38+00:00 URL: https://externals.io/message/47684#47972 · In reply to: #47970 At 14:12 15/04/2010, Ferenc Kovacs wrote: >Agree, I thought that the include part will be handled from the application. Not sure what you mean by that. >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. Assuming you meant '... merging them to the original global config', then as far as I understand that's exactly what's on the table (if&when include is implemented). So I'm not sure what exactly you're agreeing with... Zeev --- ## #47973 — Zeev Suraski — 2010-04-15T11:21:03+00:00 URL: https://externals.io/message/47684#47973 · In reply to: #47969 BTW - I think the include discussion is very much secondary here. I'm not sure why we really need include for this particular config file, and it may make sense to separate these two things altogether - moving to fpm.ini, and whether or not we want .ini files to support include. Zeev At 14:11 15/04/2010, Zeev Suraski wrote: >At 13:56 15/04/2010, Derick Rethans wrote: > > […] > >Derick, > >You're confusing syntax and semantics. >The syntax is very much .ini, it's identical to php.ini's syntax. >The semantics is designed to fit the needs of >FPM. If you follow my emails on this topic >you'd see that this is what I was pushing all along, nothing new here. >It's much like the syntax of the current config >file is XML - but we could implement the semantics in dozens of different ways. > > > […] > >I completely disagree. > >Zeev --- ## #47974 — Ferenc Kovacs — 2010-04-15T11:30:50+00:00 URL: https://externals.io/message/47684#47974 · In reply to: #47973 > BTW - I think the include discussion is very much secondary here. I'm not > sure why we really need include for this particular config file, and it may > make sense to separate these two things altogether - moving to fpm.ini, and > whether or not we want .ini files to support include. > Yep, this what I'm trying to say. I thought that the include parameter in the global.ini is just a normal config variabla, which isn't interpreted by the php parse ini method, only just tells the fpm, to include that files manualy and merge the contents of that files into the original configuration parsed from the global.ini. But as far as I understand the patch and the discussion, it seems that Jerome proposed to change the internal working of the ini parsing, to add general support for includes. Tyrael --- ## #47976 — Zeev Suraski — 2010-04-15T11:38:03+00:00 URL: https://externals.io/message/47684#47976 · In reply to: #47974 At 14:30 15/04/2010, Ferenc Kovacs wrote: >Yep, this what I'm trying to say. I thought that the include >parameter in the global.ini is just a normal config variabla, which >isn't interpreted by the php parse ini method, only just tells the >fpm, to include that files manualy and merge the contents of that >files into the original configuration parsed from the global.ini. >But as far as I understand the patch and the discussion, it seems >that Jerome proposed to change the internal working of the ini >parsing, to add general support for includes. Actually as far as I understand what you wrote in the 1st paragraph is exactly what was planned. There weren't any plans to touch the .ini parser itself in any way. What I said beforehand is that there are two ways to implement include: 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. 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'. Zeev --- ## #47977 — jerome@loyet.net — 2010-04-15T11:47:42+00:00 URL: https://externals.io/message/47684#47977 · In reply to: #47976 2010/4/15 Zeev Suraski : > At 14:30 15/04/2010, Ferenc Kovacs wrote: > > […] Not especially. I always wanted to implement includes into FPM and not widely into zend_ini_parser. > > Actually as far as I understand what you wrote in the 1st paragraph is > exactly what was planned.  There weren't any plans to touch the .ini parser > itself in any way. > What I said beforehand is that there are two ways to implement include: > 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 > 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 ! --- ## #47979 — Zeev Suraski — 2010-04-15T11:55:42+00:00 URL: https://externals.io/message/47684#47979 · In reply to: #47977 At 14:47 15/04/2010, Jérôme Loyet wrote: > > […] > >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... > > […] > >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? Zeev --- ## #47980 — jerome@loyet.net — 2010-04-15T12:04:16+00:00 URL: https://externals.io/message/47684#47980 · In reply to: #47979 Le 15 avril 2010 13:55, Zeev Suraski a écrit : > At 14:47 15/04/2010, Jérôme Loyet wrote: > > […] > > 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. > > > […] > > 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. --- ## #47982 — Ferenc Kovacs — 2010-04-15T14:00:38+00:00 URL: https://externals.io/message/47684#47982 · In reply to: #47976 > At 14:30 15/04/2010, Ferenc Kovacs wrote: > > > […] > > Actually as far as I understand what you wrote in the 1st paragraph is > exactly what was planned. There weren't any plans to touch the .ini parser > itself in any way. > - the include directive is not yet implemented because the zend_ini_parser is not able to handle recursive calls (because of the the state env which is global) This seems to like that Jerome is implying to change the zend_ini_parser to support includes. If the includes are done by the fpm config loader/parser, then I don't understand why should the zend_ini_parser to be changed except the one case that Jerome wants to implement a general include support for the ini parser. Tyrael Tyrael --- ## #47983 — Zeev Suraski — 2010-04-15T14:13:02+00:00 URL: https://externals.io/message/47684#47983 · In reply to: #47982 At 17:00 15/04/2010, Ferenc Kovacs wrote: >On Thu, Apr 15, 2010 at 1:38 PM, Zeev Suraski ><zeev@zend.com> wrote: >At 14:30 15/04/2010, Ferenc Kovacs wrote: >Yep, this what I'm trying to say. I thought that >the include parameter in the global.ini is just >a normal config variabla, which isn't >interpreted by the php parse ini method, only >just tells the fpm, to include that files >manualy and merge the contents of that files >into the original configuration parsed from the global.ini. >But as far as I understand the patch and the >discussion, it seems that Jerome proposed to >change the internal working of the ini parsing, >to add general support for includes. > > >Actually as far as I understand what you wrote >in the 1st paragraph is exactly what was >planned.  There weren't any plans to touch the .ini parser itself in any way. > > >- the include directive is not yet implemented because the >zend_ini_parser is not able to handle recursive calls (because of the >the state env which is global) > >This seems to like that Jerome is implying to >change the zend_ini_parser to support includes. Not quite - he only wants to make the parser reentrant, so that it would be possible to implement include in a certain way. It doesn't mean the parser itself will support include. BTW - I think there are other ways to implement include that don't require making the ini parser reentrant but that's a different story. >If the includes are done by the fpm config >loader/parser, then I don't understand why >should the zend_ini_parser to be changed except >the one case that Jerome wants to implement a >general include support for the ini parser. In Jerome's approach the include logic will still be at the fpm config loader/parser level, but he's modifying the ZE ini parser slightly to make it easier for him to implement it at that level. The behavior of the ZE ini parser won't change. Zeev --- Next page: https://externals.io/message/47684.md?page=2