2010/4/15 Zeev Suraski <z...@zend.com>:
> At 17:00 15/04/2010, Ferenc Kovacs wrote:
>
>
>> On Thu, Apr 15, 2010 at 1:38 PM, Zeev Suraski
>> <<mailto:z...@zend.com>z...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to