On 24.10.2007, at 20:35, Stephen Deasey wrote:
> 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!"
>
>
OK. I buy everything.
So, supported conversion rules:
Unknown -> any
Int -> Unknown
Bool-> Unknown
and unsupported:
Int -> Boolean
Boolean -> Int
(more types like floating, wide can be introduced later, if needed).
Commands ns_getconfig/ns_setconfig ?-type? I would leave as is.
Without the specific type, if the argument is already set,
the conversion is done as any->unknown (AND the parameter
shimmers). If the parameter is not there and default is given
it is recored as Unonown type. In all other cases, type-checking
is introduced.
Do we now have consensus here? I would not like to change the
code every 5 minutes, so lets stick to (any) spec and go from there.
I believe we have something good now that we can build upon.
-------------------------------------------------------------------------
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
