2010/3/25 Jérôme Loyet <jer...@loyet.net>: > I made some conf file exemple to really see what it will be: > > <snip> > > http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html > > From my point of vue, a conf file should be the less redundant as > possible and should be splitable in different files (in the case of > huge conf file, or when several administrators work on the conf files, > each pool has a file, and each pool administrator manage its own > file). So the INI syntax with sections to seraparate pools, with > include and the default pool is, for me, the best options we have > here. It's quite simple, it's clear and customizable. > > To compare, I put the same in the current XML syntax : > http://www.fatbsd.com/fpm/xml.html > > what do you think ? > > ++ Jerome
http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html Hey, Thats the ticket Jerome! Maybe we have our winning INI scheme yet eh? Maybe id suggest (on top of that scheme), the main config file (which you labelled "/etc/fpm.conf"), to need only just the overidden options users want? So therefore the factory defaults file would be included earlier on, and tucked away somewhere else? Apart from that 1 suggestion, I cant see anything to improve upon. The standard seems good. I dont know if the whole internals list and / or Antony would agree but in anycase, this thread seems pretty exhausted now. If you intend to implement this Jerome, then perhaps (any time when / after you implement), just make new (seperate) RFC for that (just the ini). Which (obviously) can be attached as single dependancy of this RFC. That way, those comments / feedback can come directed back for just you (on your chosen, preferred ini implementation). And we don't get confused over the other ini examples. Best regards dreamcat4 dreamc...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
