On 10/23/07, Vasiljevic Zoran <[EMAIL PROTECTED]> wrote:
>
> On 23.10.2007, at 21:24, Stephen Deasey wrote:
> >
> > But one of the things we want to support is introspection, right?
>
> Right.
>
> >
> >
> >   foreach section [ns_getconfig] {
> >       foreach {k v} [ns_getconfig $section] {
> >           ...
> >       }
> >   }
> >
> >
> > The only way to make it work atm is to pre-declare all config values:
> >
> >
> >   # mylib.tcl
> >
> >   ns_setconfig section enabled true
> >   ...
> >
> >   proc foo {} {
> >       if {[ns_getconfig section enabled]} {
> >           ...
> >       }
> >   }
> >   ...
> >
> >
> > Pre-declaring is a new restriction. Is this the plan?
>
> Well, I went ahead in making it ns_config compatible
> although this may NOT really always be clear.
>
> If you do not set default values, then module A might
> have different defaults then module B, which is right
> and wrong, depending on the position...
> If you however set them in module A, might that have
> side-effects in module B ?


If you have:

    ns_getconfig section theint 42

and somewhere else you have:

    ns_getconfig section theint 13

and you set it up so that on the first access, if the value does not
exist in the global config you seed it with the default (as you must
if you want introspection to work), then the value seeded depends on
which code runs first.

I don't think this is necessarily an error. By design it's a
read/write config, so if the value started at 42, maybe someone reset
it to 13?  It's the same effect.

However, I think this would be an error:

    ns_getconfig -bool section key yes
    ...
    ns_getconfig -int section key 1

The two pieces of code share a config key but they have conflicting
ideas about the type. One of them is wrong.

The alternative is to always store the string value and do conversion
on every access. I don't think this is the way to go: it's slow and
it's just not logically correct.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Reply via email to