Le 23 avril 2010 14:15, Derick Rethans <der...@php.net> a écrit : > Moving this thread to internals, where it belongs. Full thread is below: > > On Fri, 23 Apr 2010, Jérôme Loyet wrote: > >> Le 23 avril 2010 13:09, Derick Rethans <der...@php.net> a écrit : >> > On Fri, 23 Apr 2010, Jérôme Loyet wrote: >> > >> >> Le 23 avril 2010 11:31, Derick Rethans <der...@php.net> a écrit : >> >> > On Wed, 21 Apr 2010, Jérôme Loyet wrote: >> >> >> >> >> >> Log: >> >> >> switch the configuration syntax from xml to ini >> >> >> It's been describe in the RFC: http://wiki.php.net/rfc/fpm/ini_syntax >> >> >> >> > I feel extremely unhappy about this patch. From what I've seen there >> >> > is only a very small group of people that want to switch from the >> >> > XML format to the INI format. Another group, was opposed to this >> >> > move. I for one, find this new INI stuff extremely complicated and >> >> > annoying. >> >> >> >> Please compare http://www.fatbsd.com/fpm/php-fpm.conf.ini and >> >> http://www.fatbsd.com/fpm/php-fpm.conf.xml >> >> Those 2 files have exactly the same values. >> >> >> >> r...@raptor> wc php-fpm.conf.* >> >> 33 28 683 php-fpm.conf.ini >> >> 48 77 1554 php-fpm.conf.xml >> >> >> >> Number of lines: 32% less lines in INI than XML >> >> Number of words: 64% less words in INI than XML >> >> Numbers of bytes: 57% less bytes in INI than XML >> >> >> >> Do you really think XML is easier to read/right than INI ? >> > >> > Conciseness has never been a synonym for readability. >> > >> > The structured approach of the XML makes it much easier to see exactly >> > which value belongs to which section. >> >> in php-fpm there is only one level of section. >> >> One section == One pool. That's all >> >> In the current XML syntax there is several level of section which are >> total useless. They have been removed in INI. > > They are still there (besides one, "section pool", but there is a new > level too): > > global (is <configuration> > section www (is <workers>, <value name='name'>www</value>) > listen > listen.allowed (this is actually a new level) > > pm <value pm> > pm.max_children > > env > env[PATH] (Why is this different again?!) > > Besides all the levels still being there, it is extremely hard to spot > them!
I think you're missing the point derick. The main goal of INI (in this context) is to get rid of redundancy and get much more write/readability. As a sysadmin I spent a lot of time tweaking several conf files. I deal with many different configuration file syntaxes (apache, tomcat, bind, nginx, postfix, and so on). And after many years touching those conf file ... I can say that XML is a pain in the ass to read, modify and write. There is so much redundancy that you loose time extracting valueable information from the parasite noise XML produces. And when you write XML, you have to loose time writing parasite XML noise for nothing ! I'm talking about sysadmins because they are the ones who will use FPM conf file. Mainly, dev will stay using apache/mod_php and even if dev will come to FPM they won't touch the conf file every day. When I want to say "I don't want FPM to start in background" I have to write: <value name="daemonize">no</value> or <daemonize>no</daemonize> or <daemonize value="no" /> You have at least 10 useless characters for 11 usefull chars. with INI it's much much clearer: daemonize = no You have 1 useless char on 11 usefull chars The FPM configuration file is simple so we need a simple syntax. Derick, do you often edit XML file on console ? If not I understand you don't understand me :) ++Jerome > >> >> > Instead of a nice ordered XML file we now have a mess of INI files >> >> > that makes me think of Windows 3.11. >> >> >> >> So in your mind you want the php.ini to be changed to xml (php.xml) ? >> > >> > No, they are two different things. php.ini doesn't need sections, or >> > nested structures whereas the FPM configuration benefits from it >> > so that you can see immediately to which part a specific configuration >> > setting belongs. >> > >> > There are two totally different uses of configuration files here, so >> > there is no reason to jump through hoops to make them look a little bit >> > the same and introducing lots of complexity at the same time. It's even >> > more ridiculous because the original XML configuration format was >> > working just fine. > > > > regards, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
