On 10/15/07, Vasiljevic Zoran <[EMAIL PROTECTED]> wrote:
>
> On 14.10.2007, at 23:34, Stephen Deasey wrote:
>
> > Here's the thread from last time (lots of good ideas):
>
> Yep. Too bad nobody peeked at the suggested
> (bare-bones) implementation. I guess I should
> just go and get it in, tagging the tree before
> the change so we can easily revert back if this
> founds to be problematic?
:-/
> Out of the numerous ideas, the really important
> one would be an option (compile or runtime) wether
> to allow config to be writable or not....
I don't think this is the most important problem.
One problem is that there seems to be a lot of memory allocation and
copying going on, even on the fast path. For example, NsConf_GetBool()
does three mallocs, a couple of copies, conversion back and forth
between string and int rep, two hash lookups and a lock/unlock. It's
not exactly (opt & FOO_OPT) :-(
Another problem is that the model is extremely basic. It seems to be
identical to nsv (with different locking) so the only way to have
dynamic configuration is to do this:
AtRuntime()
{
if (ConfigGet("enabled")) {
...
}
}
- This will be a problem for some code because it's too slow.
- Some configuration parameters depend on other ones or on some
computation like converting units. ATM this is done once at startup.
But with this scheme it would have to be inline with the code that
used the param (or perhaps wrappers..).
- Some changes in config values should trigger other code to run -- it
is an event, it is not polled. For example, some threads might need
killed off or created within a pool, or a proc should be scheduled.
- One of the problems mentioned was inventorying config params. For
example, some config params are guarded behind a check for 'enabled'
-- if it's not enabled the other params won't be checked, and they
remain hidden. I guess this module doesn't help with this, maybe it
shouldn't..?
One way of looking at it might be that this will not handle all config
situations. I think the problem with that is:
1: It is confusing. We are saying: config is read write. But when you
write some config params, nothing changes. It is doubly confusing
because some of those params *will* be changeable, but only by calling
ns_fooctl.
2: This scheme would nicely handle non performance critical key/value
config called from Tcl code. But if you can already do that with
nsv...?
I still agree that a more runtime configurable server is desirable.
-------------------------------------------------------------------------
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
