2010/3/24 dreamcat four <dreamc...@gmail.com>: > Wait a sec, > > As a previous maintainer, I dont believe I should really have as much > weight in this decision as the rest of the internals group. It does > seem like plenty enough discussion over this INI business. Theres now > over 40+ mails on this thread, mostly about ini. And this is not the > only discussion we ever had about this either. I agree with Stainslav > that we shouldnt let it go unresolved because... well, because thats > exactly what happened when we discussed ini files for FPM last time.
I agree with you here. The last time we talked about that, it ended nowhere. it seems to be a passionate debate, so lets end it once and for all. > > Overall, it seems the positions of Stainslav and Zeev are generally > representative of this thread. I don't have any worthwhile arguments > throw against those views. They all seem balanced and well intentioned > enough. And it would be great to draw a line under the whole RFC. Ie > by stating that we only need to add just 1 specific feature to FPM to > get it officially accepted. > > Now that Zeev (and if not Zeev then Stainslav) have been kind enough > to openly commit to writing a patch for this, thats absolutely great > progress. Of course we also dont want to miss out on all the major > rewrite work Antony has been doing recently with FPM, which is also > absoultely essential to a future with FPM. > > Its understandable to be worried about letting the standards of the > code slip, when Antony has been trying so hard to clean up the > existing codebase. So its not unreasonable unreasonable to be a little > concerned that we would make the code harder to maintain by including > INI syntax. Some of the struggle seems not adding INI, but adding it > in a way thats clean and easy to maintain. On the other side of the > coin, rejecting Zeevs offer for a patch would mean failing to satisfy > the RFC consensus. Surely we can know what kind of good code to expect > with Zeev and Stainslav here, based on their past work for PHP? > > If the problem is all arguing over these finer points / differences > then id suggest that those seem less like big issues to the rest of > us. Either way, this INI thing does seem to be pretty much the only > thing people are asking for here. So it seems accurate (to me) to > label "any reasonable INI syntax" as the 1 resulting RFC consensus? > > That would mean the RFC is not necessarily be an outright requirement > to remove the xml. I mean you might conceivably want xml to remain for > a while as a legacy option. Or have it the other way round, where the > INI option is disabled by default until we are confident that it > properly satisfies the RFC. About INI, we heard differents syntaxes (with or without sections, dot separation, ...). I made some conf file exemple to really see what it will be: ** Full Verbose ** It means that eveything is prefixed by the pool name (like pool.www_site_com.group = www). I added also the same conf file with includes: http://www.fatbsd.com/fpm/ini_full_verbose.html http://www.fatbsd.com/fpm/ini_full_verbose_with_includes.html ** Sections ** In this case, each pool is identified by a section. This way, we can use dot and space in pool name and we remove useless redundancies in keys ("pool.www_site_com.user = www" become "user = www"). If there is less redundancy, this is easier to read and write. I added also the same conf file with includes. http://www.fatbsd.com/fpm/ini_with_sections.html http://www.fatbsd.com/fpm/ini_with_sections_and_includes.html ** Default Section ** Talking about redundancy. When there is more than one pool, there is several parameters which remain the same. Why should we type them several time ? The idea is to define a special pool, which will not be started but only be used as a "template" with default values for other pools. Common parameters will be set in the default pool and in each pool only specifics parameters will be set. here some example in the two previous cases http://www.fatbsd.com/fpm/ini_full_verbose_and_default.html http://www.fatbsd.com/fpm/ini_full_verbose_and_default_and_include.html http://www.fatbsd.com/fpm/ini_with_sections_and_default.html 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 > > On Wed, Mar 24, 2010 at 8:46 AM, Antony Dovgal <t...@daylessday.org> wrote: >> On 24.03.2010 11:29, Zeev Suraski wrote: >>>>I think you're missing something. >>>> >>>>I don't care if FPM is in or out of the core. >>> >>> FWIW, I don't think it's a good start for a component that goes into >>> our distribution. >>> In this case I'm willing to take responsibility for doing the >>> conversion, but for the record, if someone proposes to put a >>> component into the PHP distro and refuses to implement the feedback >>> (not every last piece of anecdotal feedback, but the key points) >> >> "Key points" is exactly what under question here. >> Taking into account that the maintainer of the branch (along with other >> people) agrees with me, >> I tend to think this point is not so major as you think. >> >> -- >> Wbr, >> Antony Dovgal >> --- >> http://pinba.org - realtime statistics for PHP >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
