On 22.08.2006, at 14:03, Bernd Eidenschink wrote:
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).
I would say: this is pretty impossible! Nobody imposes any known set of
config options to the underlying implemntation so the implementation
cannot
do any "sanity" checks beside basic type-checking.
You can pretty much say:
ns_section milly/vanilly
ns_param fate 1
and the ns_config will swallow this peacefull, althought you really
wanted
to say:
ns_param fake 1
If we could define all possbile options of "milly/vanilly" section
somehow, then it would be possible to do checks like that.
Hm... perhaps this is not that bad idea at all. What about:
ns_section name ?args?
where args would give a list of all supported parameters for that
section? Then the implementation could easily complain if you
misspelled the parameter. But this leaves you with abother trouble...
What if you say:
ns_section mily/vanilly
(note one "el" missing in section name) then you are also out of luck.
To cover that, you would need to be able to give all sections in advance
which is, of course pretty weird. Given the amount of work to do that
*properly* I'd rather opt with the basic type-checking we have now.
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...
Exactly.
Cheers
Zoran
