[Nagiosplug-devel] Access to CVS as a developer

[Howard Wilkinson]

Karl,

if you have some examples of your thinking I would appreciate a look. 
Will see if I can incorporate it into my approach.

I have implemented a structural solution for Perl, which produces both 
the help and usage outputs from the structures, and allows the XML 
version to be switched on by using a --xml flag to the command. I am 
thinking on adding a general output package (to the Perl stuff at least) 
that would generate XML output as well as the textual stuff that Nagios 
currently uses.

Currently XML dumper is home grown. But I have a prototype DTD and am 
looking at an automated dumping facility. I am currently working through 
the 47+ perl plugins in the CVS Head to use this facility. But the data 
definition is ugly and I think unacceptable. See example check_apache 
attached. However, if I can find a way of tidying this up, then with a 
small extension to the DTD, I think I can generate the option parsing 
and checking code automatically from the data structure, add the usage, 
help, version and possibly even the verbose options to the output 
stream. And make the result reporting much easier to use. Which should 
make it easier for people to write (at least Perl) plugins, with a 
richer set of facilities. I have yet to tackle the problem in `C' which 
is going to be larger if only because of storage allocation requirements 
- but may be easier to come up with a clean interface using VERY clever 
pre-processor code. And then PHP (should be easy-ish), Python (will have 
to dust off the cobwebs in the brain for this one) and finally SHell 
(which is likely to be nigh on impossible even though I am quite good at 
making SHell do what I want eventually).

So any alternative approach that will get me what I want and make 
everybody else's life easier would be useful.

Regards, Howard.

Karl DeBisschop wrote:

>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
>  
>

-- 
Howard Wilkinson
	Phone:
	+44(20)7690 7075
Coherent Technology Limited
	Fax:
	+44(20)79230110
33 Belgrade Road, Stoke Newington,
	Mobile:
	+44(7980)639379
London, United Kingdom, N16 8DH
	Email:
	<mailto:howard at cohtech.com>howard at cohtech.com




This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from you system.

E-mail transmission cannot be guarenteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20040320/a75e28e9/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: check_apache.pl
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20040320/a75e28e9/attachment.pl>