Re: [naviserver-devel] read/write ns_config

[Zoran V. <zv...@ar...>]

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