Re: [naviserver-devel] read/write ns_config

[Mike <nee...@gm...>]

On 8/23/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> On 23.08.2006, at 17:20, Andrew Piskorski wrote:
>
> > That's only necessary to preserve the current ns_config
> > case-insensitivity, right?  Wouldn't it be easier to just canonicalize
> > the key values on both write and read?  E.g., create a wrapper around
> > nsv which forces all keys to all lowercase.  Then the key "Foo_Bar"
> > will be automatically translated to "foo_bar" in all situations.
>
> This is also a posibility I was thinking of. This would work, but then
> if you would want to generate a dump of the config later on, you would
> loose the case.
>
> If somebody made this:
>
>   ns_config ns/section/something
>   ns_param MyParam 1
>
> and if we would to re-create the setup
> in order to put it in the file again,
> the case would be lost, so the param
> will not be called "MyParam" but "MYPARAM"
> or "myparam" whatever case you selected.
>
> I do not know if this is/would-be an issue
> for anybody, but this is important to know.
>
> If you ask me: I would go with that and with
> the nsv as I believe this is most optimal in
> case of needed work and final result. But I
> must see that we do not shoot ourselves in
> the foot by some wrong design decision. Hence
> so much fuss.

Reading today's developments on this thread, I am glad to know that by
the time I got to the bottom others had the same thoughts as I.
Reusing nsv for the config makes most sense to me - removes code to
add functionality and flexibility.  This always seems like the correct
path.  Making the config file canonical isntead of the silly case
insensitivity also makes a lot of sense.

I do think a sanity check is in order when reading the config file -
while dealing with config file and collapsing the case, it makes sense
to check that no other case-version of the same key has been seen and
at least issue a warning.  This might be a bit too expensive to
include, but maybe a good idea.

I do have one concern with this change - what happens when the value
(where case must be preserved) for some key is actually the name of
another section or key?  I do not have enough experience to tell if
this is ever a problem, but I am not sure how this situation would be
handled.  Perhaps by the code that uses that config value?