On Fri, 2009-09-04 at 13:55 +0200, Sylvain Jeaugey wrote:
> On Fri, 4 Sep 2009, Jeff Squyres wrote:
>
> > I haven't looked at the code deeply, so forgive me if I'm parsing this
> > wrong:
> > is the code actually reading the file into one list and then moving the
> > values to another list? If so, that seems a little hackish. Can't it just
> > read directly to the target list?
> On the basic approach, I would have another suggestion, reducing parsing
> and maybe a bit less hackish : do not introduce another file but only a
> keyword indicating that further overriding is disabled ("fixed",
> "restricted", "read-only" ?).
>
> You would therefore write in your configuration file something like:
> notifier_threshold_severity=notice fixed
> or more generally :
> key=value flags
>
> Maybe we don't have a way to differenciate flags at the end with the
> current parser, so maybe a leading "!" or "%" or any other strong
> character would be simpler to implement while still ensuring
> retro-compatibility.
>
Sylvain,
The current parser eats up all characters after the "=": everything that
is between the "=" and the eol is considered as the paramter's value.
So the second approach you're proposing seems better to me.
But if we do this, the extesension I proposed in my RFC will be harder
to implement:
============
This new functionality can be extended in the future in the following
way: allow the administrator to specify boundaries within which an MCA
parameter is allowed to be changed by a higher priority setting. This
means that the administrator should declare min and max values (or even
a set of discrete values) for any such parameter. Then, any higher
priority setting will be done only if the new value belongs to the
declared set.
============
But actually, may be that extension is not desirable at all. In that
case, I agree that your prposal is a very good compromise:
. single parser (though it should be enhanced)
. single configuration file
Regards,
Nadia
--
Nadia Derbey <nadia.der...@bull.net>
