Hi,
>> First: >> as I can say, the new structure is applied to almost every file >> (with different success) in the reference part > Nice ;) but has to be improved with some content.... [...] >> As far as my knowledge goes, I added the ini.xml to the extensions in >> en/reference. Therefore I used scripts/mk_ini_set_table.sh contributed >> by Jesus M. Castagnetto, thanks!, and a quick look into the current cvs >> sources. >> Some questions are still open: >> Take ncurses/ini.xml as example. >> ncurses.value"42"PHP_INI_ALL >> ncurses.string"foobar"PHP_INI_ALL >> >> Does this make sense? More ini entries like this exists, e.g. for >> tokenizer. Apply them, leave them? >> If someone more experienced could take a look... > Well, I am not experienced in the ncurses interface, so I cannot see > what is the real problem here. No real problem, I'll add them to the extensions they belong to. >> Third: >> What about the general, not extension specific, ini entries, like them >> for e.g. safe mode? Where should they go? To features/safe mode? >> What about e.g. Error Logging related entries? >> Will chapters/config.xml exist in the future and in which form? >> Should all general ini entries(in the above sense) go there? > This is a more general question. What to do with details most of > the time put into extension docs, but are general. Like general > ini settings (asp tags for example), general constants, etc. > Constants fit quite well in the "predefined appendix", while ini > options may go to the ini_set function documentation, or be > left in the config.xml. Therefore I asked. Personally I like the idea of a "global" config.xml with all global ini entries. In doubt, if an entry belongs to a specific extension or may also be global, I prefer to leave the ini entry in config.xml and linking from the extension/function to the relevant setting. For example: set_magic_quotes_runtime It would make no sense to move the ini entries for assert/magic_qoutes etc. to info/ini.xml...... In this case the contents of config.xml should be changed to hold the infos about PHP_INI_All|PHP_INI_PERDIR etc.for each setting. Moving the infos to ini_set seems not a good idea for me. The same for the ini constants, they should go to config.xml imho. For safe mode and error logging I would like to move the info to features/safe mode resp. Error Handling and Logging Functions and linking from config.xml One more thought about Error Handling and Logging Functions: closelog, define_syslog_variables, openlog, syslog are under Network Functions. Historical reasons? Imho they would better fit into the Error Handling and Logging Functions, but thats in whole a really different question. > The same question will arise, if you [we] start moving the configure > options around, which is actually the same change as the ini setting > distribution around extension parts. Just they will go to configure.xml > files. There will be general options left which should go somewhere... yep. >> Fourth: >> About the changelog issues: for ini entries it might be of some >> interest to add the infos about the availability asap. But how? > It's quite hard work to dig into the CVS and find out how and when > ini options changed/added/removed and how the treament of values > changed. I think that this should not be a priority. +1, I thought/hoped the devs could us give some infos about this point. > Much important > is to go on with the configure options distribution, thus deleting > many files from the chapters dir, and so then we will be able to > deal with the installation chapter quite clearly. This is how I would > imagine the roadmap for the short time. +1 > Goba Friedhelm -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
