[RFC] FPM INI syntax View as Markdown

Le 15 avril 2010 13:55, Zeev Suraski zeev@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.

Agreed that it's a big change, but it's certainly possible.
Requires its own discussion...

Fwiw +1

Mysql's ini file supports includes (!includedir and it supports
wildcards), so people are used to the syntax and it can follow a
pseudo-standard if you may.

Ideally all ini parsing would support it. Kills multiple birds with
one stone. I can see many applications for this. Might want to ensure
parse_ini_file() has no security issues though by allowing it. If so a
flag whether or not include syntax is supported should be put in and
pass it as false for that "userland" function.

Php aleady supports scanning a single directory for more config info
but different distros use it differently and it can only be changed
during configure time. This negates that need too.

Slighty OT but also slightly relevant :)

At 17:00 15/04/2010, Ferenc Kovacs wrote:

On Thu, Apr 15, 2010 at 1:38 PM, Zeev Suraski <mailto:zeev@zend.com

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.

"There weren't any plans to touch the .ini parser itself in any way."

I think that for the long run, it would be better, that the php-fpm and the
php core only differs on the parts where it's neccessary (either it will be
merged to the core or not), and I think it is not neccessary, for example
the additional ini file parsing doesn't need this modification, why should
the php-fpm?

Tyrael

2010/4/15 Zeev Suraski zeev@zend.com:

At 17:00 15/04/2010, Ferenc Kovacs wrote:

On Thu, Apr 15, 2010 at 1:38 PM, Zeev Suraski
<mailto:zeev@zend.comzeev@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.

the include logic will be at the fpm config loader/parser level but I
DON'T want and I WON'T to change the ZE ini parser (even slightly). So
I won't touch anything but the FPM files. I didn't want to create
confusion or something on this point. It was not my point.

To be precise, I wanted to call recursively the zend_parse_ini_file
function but it's not possible (because of a global state --
state_stack -- variable in the ZE ini parser). So I'll continue to use
the zend_parse_ini_file as is and change my code to make it works with
this constrain.

We can still start another discussion about adding include support or
recursive support to ZE ini parser, but there is nothing to do with
FPM and I won't do it anyway.

hope it's clearer now !
++ Jerome