Here's what we ran into when we did something similar; just cautionary information, not trying to shoot anything down here.
Our approach was to create a separate repository / heirarchy of configuration variables that is *not* module oriented, but administrative task oriented. So, for example, we have a section called "ServiceNetwork" with a variable called "HTTPInterface". That variable gets one or more IP addresses. Only these variables are dynamic. To get a dynamic update for one of these variables, any piece of C/C++ code registers a callback based on the variable name. This repository is read at startup, before the normal ns_section/ns_param file. The declarations for these variables state whether changes to the variable require a server restart to take effect, or not. Our management console works entirely in terms of this repository; the ns_section/ns_param variables are never mentioned anywhere in our product documentation or configuration interfaces. If you change a value that is can't be managed dynamically, an indicator comes on saying you need to restart. This comes on for every management console, so if I change a variable and you also have the console up, you see it the indicator. The nsd.tcl-equivalent, which is still written in terms of ns_section/ns_param, then has access to those variables as TCL global variables (just a convenience, not necessarily my best design idea). If more than one module needs access to a configuration variable, they just use it in this section. That lets us use normal AOLServer modules out-of-the-box, yet coordinate their tuning by writing complicated TCL. For example, we configure both the number of Conn threads and some of the resources for our publish-subscribe system based on variables called "Workload/NumberOfSubscribers" and "Workload/NumberOfPublishers". The publish-subscribe system can register a callback to adjust its tuning on the fly; the conn threads can't, but aren't quite as sensitive to it. The positive implications have been: * People configuring our system rarely have to copy the same parameter to different sections. * People configuring our system never have to write TCL. * No changes to existing modules are required * Our modules, or our own edits to AOLServer modules, get dynamic capabilities * All configuration changes can be made over HTTP * All of our modules have dynamic debug capability; in fact, for almost all of them, it's possible to adjust their debug settings over HTTP, so you can almost get to the point where you can debug a specific HTTP request (of course, with lots of traffic, that doesn't work). The negative implications have been: * Our nsd.tcl-equivalent is *very* long and complicated (~3000 lines), and is gradually becoming dominated by TCL control statements (if/for/etc), not sections & params. * If a variable requires calculation to become an internal configuration state, the calculation is often repeated in both TCL (nsd.tcl) and C. * Startup time is slowed by all this processing, but it's not a big deal because we also recover a database during our startups, which dominates the startup time. * It is very hard to see all the coupling for a specific variable. * Any module that uses a dynamic variable has to code for it three times, in three different areas: once for its use for ns_section/ns_param, once for the global configuration area, and once in the callback. We could mitigate some of these with better generators or code conventions, but haven't. -- ReC -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zoran Vasiljevic Sent: Friday, August 25, 2006 3:20 AM To: naviserver-devel@lists.sourceforge.net Subject: Re: [naviserver-devel] read/write ns_config On 24.08.2006, at 21:36, Stephen Deasey wrote: > > So I think you can't get away from specialisation, unfortunately. > What I still cannot (easily) accept is that we can't do a config module as repository for the server and other module's configuration options. Think of it as the Windows registry (not that I'm a fan of Microsoft, I'm not, but this "centralized" approach also has benefits). What I could imagine is: We can have the config file as is now. But it would form just a part of the configuration. Over the runtime of the server, new configuration could be added or existing changed. This is non-volatile, means at the next restart, the changes are still there. At the startup, one can decide wether the config file (as now) is the applied first or after loading the, lets call it registry for now, file. This way you can decide wether the changes to the values from the config file are overriden by the registry or not. New stuff which is only in the registry is of course loaded. But during the startup you can even discard them completely. We can have a web-page which handles registry maintenance in the server. So with one management interface you can tune various knobs mostly w/o restarting the server. The persistency can be implemented by a simple dbm hash-file (ndbm, gdbm). I mean, nobody can tell me that this is impossible or not practicable: there are at lest 60.000.000 proofs of concept out there... I would need to hear 1 good reason against this. As you see, I'm not letting loose... As the matter of fact, I will write this for us internally as a module. Lets call it "nsregistry" module. It will have a library to link with so other modules can use it from the C-level. It will have a Tcl and C API similar to what we have now, with a small difference: values are obtained by *copy* and not by reference. It will be properly locked so it can be used from many threads at the same time. I will of course not repeat the silly case-insensitivity junk: the thing will be case sensitive. It will have the same section/parameter approach as the current config. The idea of this module would be to provide centralized and persistent storage for all kinds of various configuration parameters one can imagine, for the server itself and for the modules. From Tcl and from C-modules. Actually, that what the current config does but w/o aiming to replace it because of all possible concerns about locking of speed (or whatever). And it will be persistent. Cheers Zoran ------------------------------------------------------------------------ - 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
