On 09.12.2009, at 20:44, Jérôme Loyet wrote:

> Le 9 décembre 2009 17:16, Pierre Joye <pierre....@gmail.com> a écrit :
>> hi,
>> 
>> 2009/12/9 Jérôme Loyet <jer...@loyet.net>:
>> 
>>>>> We already discussed pros/cons of the two solutions. But why don't we
>>>>> allow several syntaxes ? And let the end user to choose the better one
>>>>> for its need ?
>>>> 
>>>> No. Thank you.
>>>> EOD
>>>> 
>>> 
>>> and why of that ? Why is it already EOD wihtout arguing ? php-fpm just
>>> started in PHP core and there is willing from people to help and make
>>> php-fpm better, which I tought was the final goal.
>> 
>> It is, however I have to agree with Tony here, adding a fpm specific
>> syntax makes little sense. Or do you have any killing arguments for
>> this new syntax (like not possible to do it otherwise, stoping point
>> etc.)?
>> 
> 
> I don't have killing arguments I just came with a discussion which
> seems fair here. Now it's xml and before it's been integrated there
> were discutions about changing it to nginx. So I bring back the
> discution here.
> 
> about multiple syntax it was a proposal which was about to make all
> users happy but the complexity and the confusion is a good argument, I
> heard it.
> 
> So let have the question another way:
> Do we keep XML or do we switch to something else ? If so, which format ?
> 
> I and some others think xml is not appropriate here because of the
> complexity. So I do think there is a need to change.
> 
> INI or other ?
> INI is used widely in PHP and users know it. But it's not well adapted
> for the actual php-fpm configuration organisation. (properties in
> sections or subsections). If choosed how will it be organized ?
> 
> If we want something else than XML and INI, we can use ngxin like or
> yaml configuration file, or other ...

as much as I like yaml, it's not a good choice here (because it would add extra 
dependency)

what about json?
php has nice json encoder and decoder

still, if ini can be adapted without much struggle we should use it.


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

Reply via email to