On 10/24/07, Vasiljevic Zoran <[EMAIL PROTECTED]> wrote:
>
> On 24.10.2007, at 19:09, Vasiljevic Zoran wrote:
>
> > So
> >
> >    ns_getconfig -bool section param 1
> >    ns_getconfig -int section param
> >    configuration parameter is not an integer
> >
> > would make you happy?
> >
>
> Lets stop and think about consequences of this...
>
> Underneath, some integer will be used to hold
> the value of the boolean param. After all,we
> have C underneath. Now somebody will go get
> integer rep of it and will receive error
> because the type is boolean. Good for the moment.
> But consider this:
>
>     ns_getconfig section param "1"
>     ns_getconfig -bool section param
>
> How should we react here? The "1" is not a boolean
> value. It is an string.


It should be 'unknown'. i.e. this:

    typedef enum {
        UnknownType,
        StrType,
        IntType
    } ParamType;

Should be more like this:

    typedef enum {
        UnknownType,
        BoolType,
        IntType
    } ParamType;


The conversion rules would be that you can go from Unknown to Bool or
Int, but not the other way around, and you can't go from Bool to Int
or vice versa.

So code like this:

    ns_getconfig section key 42

would set a value of unknown type if not present. Code like this:

    ns_getconfig -int section key 42

would cause it's type to become Int. It's then OK to follow that sequence with:

    ns_getconfig section key 42

again. The underlying C code would actually return a Tcl Integer type,
but that doesn't matter.

If you don't specify either -int or -bool then you're either setting
an unknown type or are happy to receive any type. Type conversion and
checking can still occur, but that's standard Tcl:

    if {[ns_getconfig section key]} { return [expr $key + 2] }

If we were still at step 1 above, they key with type Unknown would be
returned as a string and Tcl would convert to an int.


It *is* kinda weird to build (but easy to use), but that's because
we're using a command designed for the read-only existing config.
Explicitly, ns_getconfig with a default param is just shorthand for
this sort of code:

    if {[catch {
        set value [ns_getconfig -int section key]
    } err]} {
        ns_setconfig -int section key 42
        set value 42
    }

The first time the code is called, when there is no record of the key
or value in the global config, there is an implicit call to set.

We want to record that 'key' is an int because that is useful:

  [-main-] Dev: config section: ns/server/server1
  [-main-] Dev: config: (null):maxthreads value=(null) min=0 max=100
default=10 (int)


And really we always want this information. So maybe ns_setconfig
should be more like:

    ns_setstringconfig section key value
    ns_setboolconfig section key value
    ns_setintconfig ?-min n? ?-max n? ?--? section key value

And if you do that, then as ns_getconfig is implicitly a set on the
first call with a default, then maybe ns_getconfig should be more
like:

    ns_getstringconfig section key ?default?
    ns_getboolconfig section key ?default?
    ns_getintconfig ?-min n? ?-max n? ?--? section key ?default?

    ns_getconfig ?section? ?key?

$ ns_getconfig
ns/foo ns/bar

$ ns_getconfig ns/foo
a b

$ ns_getconfig ns/foo a
type int value 42 min 0 max 99


Or, considering this common idiom:

    ns_section "ns/foo"
    ns_param  bar greeble  ;# Oh, Hi!


    ns_setstringvalue ?-description d? section key ?default?


$ ns_getconfig ns/foo bar
type string value greeble description "Oh, Hi!"



> > A buffer size of 'no' doesn't make any
> > sense.
>
> But
>
>   ns_getconfig section buffer no   (module A)
>   ns_getconfig section buffer 1000 (module B)
>
> is the application problem, not ours.
>
> This is simply clash of config params. I do not
> think we need to take care of that.


The above would not throw an error, they're of Unknown type. It would
throw an error if one specified -bool and the other -int. But that is
an error (of the application).

A single key in a section can't have two types at once. You can treat
it as two different types once you get it into Tcl, but that's just
standard Tcl.

-------------------------------------------------------------------------
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