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
