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
