Generally using xml instead of ini format would allow many things.... -different ini sections for different sapis -different ini sections for different users -maybe inclusion of subscripts (db admin may change only database parts..) -maybe different ini sections for different webservers if we can distinguish before loading ini -and other handling other differences we may have now or will have to handle in the future.
but first of all we should have a dtd or xschema for this and then xml parsing is slower than ini parsing and the components needed to parse the xml settings file have to be all core components (without usage of external libraries) and that would violate thinks like --disable-xml besides that i would agree but my guesses are that no one will be found doing all the code changes.... (i skipped reply to general list because i only reply to means of development) marcus At 21:31 16.05.2002, Michael Dransfield wrote: >I have started writing an app which helps (mainly win32, new) users to >generate config files correctly to prevent glaring security holes on >production servers. > >I started by using parse_config_file(), but this ends up causing problems >because it strips comments. This means that some variables which are >commented are lost from the program. There are also potential problems >because some of the config file has [sections] and some of it >doesnt. Some of this is valid in win32 environments and some are >not. This can cause problems if users download the win32 default config >file and then upload it to Linux or BSD, it will fail. > >Will uncommenting some of the variables (and then setting them to the >default) affect the running of php at all? is there a reason why they are >commented and not just set with their default / NULL value? > >I then began playing with an xml file which stores the comments and >variables along with other useful information relating to the >configuration variable. I then added warnings to the XML document so that >the front-end can read if a setting is potentially insecure (in the >current environment). I think the best way to explain it is by looking at >the attached file, most of it is obvious, i have commented where necessary. > >Do you think this format looks OK, I am sure i have missed a lot of >information which could be of interest, for example storing a default >value with each variable, which could be different in different >environments (eg <default env="dev" value="1"/>). Maybe add a severity to >the warning. > >What would you think about the possibility of including the XML ini file >format in later release of php? it is easy enough to parse the file when >the server is started as easilly as it can parse the current ini >file(?). It could enable many possibilities because is can store multiple >environments within it, along with relavent information about the setting >itself, which would make overall administration much much easier, and >quicker. ini files are soooo Windows 95, dont you think? > >I am going to write the front-end as a web application and as a php-gtk >app (hopefully with the same code). > >Does anybody have any comments or suggestions (or would like to >help)? (please try to keep them constructive ;) i have looked for >similar projects, but cant find any. > >Regards >Mike > > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
