Re: [naviserver-devel] read/write ns_config

[Zoran V. <zv...@ar...>]

On 22.08.2006, at 18:31, Rick Cobb wrote:

>
> 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).

This is true. If we had a counter on an parameter, we could dump
the whole config tree where counter == 0. This would probably mean
that those have been set by somebody, but never used.
Although I can understand this, somebody has to show me any
practical use of it. You can catch typos with that, allright but
this is at the wrong side of the street! I would expect the server
to refuse booting in such case. Or, emit a big fat error log during
startup. Not at shutdown.

>
> 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.

You know, I have this "requirement" is sitting for about 4 years in my
todo list. I was not very keen on getting it out as I know that it
might bear some security (more important) and locking (less important)
issues. But we've come to a point where we either have to abandon
the whole ns_config stuff and write everything ourselves OR to
get this modification in the core server. Needles to say that I
hate reinventing the wheel over and over again. Hence the decision
to try to get it done with existing ns_config code.

Basically,  most important information is: from the two (are there  
more?)
issues (locking and security) which of those two is more
important/sensitive/whatever to everybody. So I know where I will
have to make tradeoffs.

Basically, all this comes down to:

a.
  should I make everything compile-time option so only people who need
  it would compile-in that code, everybody else being not affected

or

b.
  should I make it runtime selectable, because people would like to
  have both, depending on the site/application

or

c.
  should I make it read/write entirely, basically ignoring both
  locking and security issues.

The simplest is of course c. The a. is next,  with b. being more/most
complex. I would of course not want to invest much work with that and
both security/locking are no problem for me, so the logical choice
for me would be c. But I do not know if everybody is ok with that.
Hence all this email ping-pong.

Cheers
Zoran