> First: > as I can say, the new structure is applied to almost every file > (with different success) in the reference part
Nice ;) > , expect sesam (for details look at reference/rsusi.txt) > No glue about this extensions , furthermore it seems to be only in > php3 CVS. Therefore it would be kind if someone familiar could apply > the new structure and the appropriate ini.xml. The Sesam extension is gone for some time now (I don't know the reason). And I also don't know what to do with the content about it. I would say delete them, but maybe someone will argue against it, putting backward compatible documentation on his flag. > 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. > 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. 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... > 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. 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. Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
