[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