My apologies. I was actually responding more to my perception of Bernd's idea than to the feature of allowing writability of the ns_config system in general.
My concern with the idea of trying to identify typos or other problems in configuration is that there are a number of ns_param sets which aren't a set of fixed names. In the AOLserver world, the ns_section for "cgi", for example, allows you to set an ns_param with any name and any value, none of which are verified by the C module, all of which are just copied to the environment array for the cgi. Now, looking @ Bernd's idea, I see, perhaps, a bit where he's going: if, for example, the ns_param dictionary had a bit saying "I've been read by a module" (no matter which language the module was in), then at server *shutdown*, you could print a report of unused ns_params and ns_sections. But really, you can't tell before then (as you've pointed out, Zoran). I'll note that in the configuration system for LiveServer, we used our publish/subscribe facilities (the stuff we sell) to handle the "write back" issues you're solving. We allow coders to register a (C-only, at present) callback for their variables, so if they change, they're informed and can immediately change behavior. We also actually write the physical configuration file; if no callback was provided, we inform the administrators (presumably one of whom is making the change) that the server needs to be restarted before their change will take effect. To do this, we use a completely separate layer of TCL variables, procs, and sourced TCL files to construct ns_section/ns_param calls. It's not elegant, and doesn't fit the real NaviServer/AOLServer world very well, but we've found it quite useful. -- ReC -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zoran Vasiljevic Sent: Tuesday, August 22, 2006 8:03 AM To: naviserver-devel@lists.sourceforge.net Subject: Re: [naviserver-devel] read/write ns_config On 22.08.2006, at 16:46, Rick Cobb wrote: > Uh, and I may be missing something about how you're thinking of doing > this, but how would you handle open configuration sets like the > environment variables for the CGI module, or the map of mime-type/file > extensions? ?? ( == do not understand) What do you mean by "open configuration sets" ?? Using ns_config, nothing is "open". It is just a query into a in-memory data structure. The fact that this query now uses no locks, and is thus "cheap", modifying it to use locks is one issue (and you need locks at that place because somebody could read and other could modify the same structure). Another issue is: some module already "consumed" the parameter at startup and will never ask for it again: what is the point in changing that particular parameter? Also, should this all be allowed anyway (security issue)? This is what I see as things to take in account. For the locking issue: I believe this is not that important as it can be easily "fixed" by storing the value got from config in a private variable and then reusing this for the time being. For the security issue: well, there might be a config option to allow this, either as runtime or compile-time option (the latter will solve any locking issues implicitly) For the sense of changing a once-read config value? Well, there isn't (sense). But that has nothing to do with the implementation. 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
