On 8/25/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
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.
It would be more flexible to create ns_*ctl commands and put them *lower* in the stack, and then build a dynamic configuration tool on top of this, than to bake a dynamic configuration mechanism into the server, and have code depend on that. For example, if you went with the callback approach that Rick mentioned (seems easiest), the callback would run the ns_*ctl command when a config value is updated. You keep your options open. If you go the other way, you have to start thinking about: do we create an interface that allows people to plug in different persistence mechanism for the back end, etc...?
