[Nagiosplug-devel] Access to CVS as a developer

[Karl DeBisschop]

On Fri, 19 Mar 2004 13:01:45 +0000
Howard Wilkinson <howard at cohtech.com> wrote:

> Ton,
> 
> I am not frustrated at the delay but worried that I may move off in a 
> direction that does not get integrated easily. I have this morning 
> picked up the CVS head and now working on integrating my patches into
> this.
> 
> A piece of advice would be useful however,
> 
> I am looking to automate an interface to NagMin to allow intelligent 
> access to plugins and commands. So that help and defaults can be 
> automatically generated. I have made a start with this and have an 
> interface that allows the registration of a plugins with the NagMin 
> database. I now want to add a learning facility to this interface and 
> have started to patch ALL of the plugins to support this. My first
> pass is to remove the line feeds and extraneous spaces from the
> print_usage output. I am now reconsidering this - although it probably
> is the easiest first step it does mean the human interface is not as
> good as is was.
> 
> So I am moving to provide an XML output probably tied to a --usage
> flag (-U for short?) and leaving the print_usage alone. So advice - is
> this more palatable! What flag(s) would you suggest I use, can I add
> an XML library requirement to the plugins - if so what base libraries
> would people like to see me use, this needs to work for `C', Perl,
> Python, PHP and SHell which is a tall order but I will try to make it
> happen.
> 
> My inclination was to expand the interface to print_usage to allow a 
> specification of what type of output to product, then encode the
> output in structures which are walked to produce the usage in whatever
> form is needed. Advantage only one definition of the data.
> Disadvantage plugin writers will need to cope with providing
> structural data rather than simple string output. I will write the
> structure walking code and put it in the utils packages and change all
> of the existing plugins (including the contrib ones) to use this if it
> is acceptable. The alternative is to provide a parallel system with
> these attributes and allow the current interface to remain. Big
> disadvantage is that this will mean supporting multiple copies of the
> information about the plugin help data.

Actually, a pet project of mine is to make the plugins with embedded
docs -- sort of like perldoc on steroids. I really don't want to put the
overhead of xmlish plus plain text into the compile plugins. But it
could be done an xml-output from an embedded doc style.

I had started on this, but had to take a step back to do i18n work. But
I'd love to move it forward again.

--
Karl