> > If, as a side-effect of your work, you will find it easy to > > implement a way to > > let ns_config return all > > a) non-core/non-default/non-c-module-specific > > you mean only those set from the "outside" i.e. config file?
Basically a way to detect a typo of the ns_param key. Something that _could_ lead to a basic configuration check. Now a typo is just a missing parameter, the server sets a default value and you'll likely not notice it. Currently the knowledge about configuration options and their defaults is burried in the source, the setting of defaults is done during startup so a check without starting a server may be impossible; beside that, collecting "default" keys and their values during startup should be possible - but the identification of unknown keys would only be possible when no more config options are read/set (see next). > > b) not-belonging-to-this-section > > give me one example about what you mean. Similar to the one above, but it would be the result of an extra lookup: does the ns_param key (of which we think it is a typo) in fact belong to another section? It could currently only be done at a stage where we know all config options are set up. ns_section ns/parameters # a fastpath entry in fact belonging to ns/server/$server/fastpath: ns_param cachemaxentry 8192 Hm. The lookup may result in n-results, as some key-names are used in multiple sections. "Unkown config option x in section y" "Config option x not known in section y, check section[s] z, z' or z''" Frankly, it is probably not worth to keep an eye on that... Bernd.
