<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> 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: <blockquote type="cite" cite="mid20040319200240.5946ac26.karl@debisschop.net"> <pre wrap="">On Fri, 19 Mar 2004 13:01:45 +0000 Howard Wilkinson <a class="moz-txt-link-rfc2396E" href="mailto:howard@cohtech.com"><howard@cohtech.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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 </pre> </blockquote> <div class="moz-signature">-- <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <title>Signature</title> <table cellpadding="2" cellspacing="2" border="0" style="text-align: left; width: 100%;"> <tbody> <tr> <td style="vertical-align: top;">Howard Wilkinson </td> <td style="vertical-align: top;">Phone: </td> <td style="vertical-align: top;">+44(20)7690 7075 </td> </tr> <tr> <td style="vertical-align: top;">Coherent Technology Limited </td> <td style="vertical-align: top;">Fax: </td> <td style="vertical-align: top;">+44(20)79230110 </td> </tr> <tr> <td style="vertical-align: top;">33 Belgrade Road, Stoke Newington, </td> <td style="vertical-align: top;">Mobile: </td> <td style="vertical-align: top;">+44(7980)639379 </td> </tr> <tr> <td style="vertical-align: top;">London, United Kingdom, N16 8DH </td> <td style="vertical-align: top;">Email: </td> <td style="vertical-align: top;"><a name="howardcohtech.com" target="mailto:howard@cohtech.com" href="mailto:howard@cohtech.com"></a><a class="moz-txt-link-abbreviated" href="mailto:howard@cohtech.com">howard@cohtech.com</a> </td> </tr> </tbody> </table> </div> <DIV><HR> 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. </DIV> </body> </html>