Re: [naviserver-devel] read/write ns_config

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

On 22.08.2006, at 17:19, Bernd Eidenschink wrote:

>
> Ok Zoran, the important part first:
>
>> I'm thinking about allowing *changes* to/of this repository
>> during the runtime. This way one could override a ns_param
>> value assigned at startup or create entirely new ns_section
>> and stuff it with bunch of ns_param so others may call
>> [ns_config] to get it.
>
> I'm all for it if it is possible. It saves us server restarts for  
> dumb issues
> like increasing maximum post sizes etc.

Right. This is very good and trivial example.

>
> Problems: I can change stacksize to "0". I can tell fastpath to use  
> 1 byte of
> memory instead 5 megs. Is memory freed? I guess it comes down to  
> "You are
> able to change everything - but be sure you now what you are doing".

As said: if the module has already consumed the value,
changing it has no real sense. If the fastpath module
already got that 5 MB and allocated the cache, it will
most definitely not ask for the size again, unless it
is programmed to do so. But, since no modules so far
assumed that config values can be changed after startup,
there will be no problems. So, you *could* change it
to 0 bytes but it will mean nothing.

>
>
>
>
> The other part: It would be nice to have the dictionary of config  
> sections and
> options along with their defaults that is created when you set  
> logmaxlevel
> to "6" (dev) or "5" (debug) in section ns/parameters...
>
> -----------------------------------------------------------------
>
> [...]
> Debug: config section: ns/server/default
> Debug: config: ns/server/default:realm value="(null)"  
> default="default"
> (string)
> Debug: config: ns/server/default:checkmodifiedsince value=(null)  
> default=true
> (bool)
> Debug: config: ns/server/default:flushcontent value=false  
> default=false (bool)
> Debug: config: ns/server/default:noticedetail value=(null)  
> default=true (bool)
> Debug: config: ns/server/default:errorminsize value=(null)  
> min=-2147483648
> max=2147483647 default=514 (int)
> Debug: config: ns/server/default:headercase value="(null)"  
> default="preserve"
> (string)
> Debug: config: ns/server/default:outputCharset value=(null) (string)
> Debug: config: ns/server/default:HackContentType value=(null) (bool)
> Debug: config: ns/server/default:urlCharset value=(null) (string)
> [...]
>
> -----------------------------------------------------------------
>
> ...available as TCL command like ns_configsections.
> For the sake of the argument, e.g. "ns_startupconfigsections".
>
> It must be the list created at server startup that DOES NOT CONTAIN  
> entries
> like
>     ns_section milly/vanilly
>     ns_param fate 1
>
> As far as I can tell this is possible because simply because a  
> value was not
> requested by Ns_Config* (Int/Range whatever) commands means it is  
> irrelevant
> for the server. At least in a sense of "get things right for startup".
> Default values are set by these commands.

HE! This is the stumbling point! The fact that something is requested by
Ns_Config is not of any importance! It could have been also requested by
the "ns_config" out of (your own) Tcl startup file!

There is no such thing as "server" configuration and the "rest" of the
configuraton. There is one configuration parameters store. Everybody
can (and does) use it during the startup. Your Tcl modules, your C- 
modules
core-server modules etc. pp.

>
> I think the listing above does also only list those and would not list
> milly/vanilly section and options. Maybe it's already there.
>
> Only then I am able to utilize TCL to diff and compare and return  
> results
> like "milly/vanilly" section may be bogus or a typo. Or that
> parameter "stacksize" does not belong to section "fastpath".

You CANNOT know if a section/parameter is a typo!
If the section (or parameter) is not found and a paramter value is  
*assigned*,
then the section (and the parameter) is/are created! Point.
This is the way how all this stuff works.
Otherwise, some central authority must declare *upfront* all possible  
sections
and parameter values. We do not have this "authority". Every module  
declares
its own.

I believe we are still not in consensus :-(
Give me an example what you mean. This is perhaps easier.

Cheers
Zoran