Potential objection to normalizing the case: ns_params for CGI
environment variables. Environment variable names are case sensitive,
and it's perfectly possible that there are applications that use
lower-case names for these. Would require changing nscgi to something
more like
Ns_param set {{variable_name} {value}}
Don't know if there are more like this. We have used a similar
configuration for setting java properties, though, and IIRC, at least
some of those required mixed-case names (ClassStuff.propertyName).
-- ReC
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Mike
Sent: Wednesday, August 23, 2006 9:35 AM
To: naviserver-devel@lists.sourceforge.net
Subject: Re: [naviserver-devel] read/write ns_config
On 8/23/06, Zoran Vasiljevic <[EMAIL PROTECTED]> 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?
------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
