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
