[Nagiosplug-devel] RFC: Plugins config file (final proposal)
Ton Voon
ton.voon at altinity.com
Mon Feb 5 15:23:22 CET 2007
Hi Sean, John and Tobias,
On 31 Jan 2007, at 15:19, sean finney wrote:
> On Wed, 2007-01-31 at 12:50 +0000, Ton Voon wrote:
>> QUOTING IN CONFIG FILE
>
> i think we should be very, very clear on this. my opinion is that
> we shouldn't do any quote parsing/interpretation, and pass what
> is given verbatim to the plugin. so for example
>
> [check_myname]
> fullname=Sean Finney
>
> would be the equivalent of
>
> ./check_myname --fullname='Sean Finney'
>
> and
>
> [check_myname]
> fullname="Sean Finney"
>
> would be
>
> ./check_myname --fullname='"Sean Finney"'
>
> and that as andreas suggested, we allow for escaping single characters
> with a backslash character (which wouldn't be necessary in any of the
> above, but might be necessary for some other reason).
>
> maybe we should just pony-up and do a formal grammar for it?
>
> inifile := (discarded|stanza)*
> discarded := (whitespace)*(commentchar freetext)? newline
> freetext := [^(newline)]*
> newline := '\n'
> commentchar := "#" | ';'
> stanza := start declarations
> start := "[" name "]" newline
> name := [[:alnum:]]*
> declarations := (declaration declarations) | nothing
> declaration := whitespace name whitespace "=" freetext newline
>
> not sure if that covers everything... for example can a stanza
> have no
> declarations?
It seems to me that the big dispute at the moment is the quoting of
the config file. I assume this means everyone is happy about
everything else in the RFC :)
I agree that there needs to be clarity on the syntax, but I don't
necessarily agree that we need to go down the road of creating a
(nother) implementation of ini file parsing. It could just be an
education issue.
Can I suggest that we start with using an existing library first - I
would choose http://ndevilla.free.fr/iniparser/html/index.html from
http://en.wikipedia.org/wiki/INI_file for the C implementation. Once
we have it integrated, we'd understand better the positives and
negatives. As Sean points out, an iniparser_getdict() to return a
list of keywords for a section would be a worthwhile enhancement to
that library - this could be something that we contribute back
upstream. If we find further down in the development cycle that this
library is not sufficient, hopefully there would be a precise list of
what features it lacks.
I'm happy to add to the RFC that the config file syntax is not
finalised, to set that expectation before we make it publicly available.
I personally think the option handling part is the more difficult bit
to code, so I don't want to get too distracted by the config syntax bit.
Ton
http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon
More information about the Devel
mailing list