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
