[Nagiosplug-devel] Last call for Perl-plugin-objects

Karl DeBisschop karl at debisschop.net
Wed May 26 16:26:09 CEST 2004


On Tue, 25 May 2004 19:29:28 +1000
Stanley Hopcroft <Stanley.Hopcroft at IPAustralia.Gov.AU> wrote:

> Dear Ladies and Gentlemen,
> 
> (To the tune of 'One Bourbon, One Scotch, One Beer'
> 
> '
> One perfdata, one XMLoutput, and one checker 
> One perfdata, one XMLoutput, and one checker 
> Hey mister plugin tender come here 
> I want a Perl object and I want it now
> '
> )
> 
> Some time ago now, Mr Howard Wilkerson, proposed an object basis for
> the Perl plugins and then performed a heculanean task in modifying
> many if not all of the standard and contrib plugins to use his
> Classes.
> 
> FWIW, I am now almost convinced of the usefulness of this approach 
> because it allows maintainers to add useful functions^H^H^H^H methods
> to   the base class to equip the plugin with
>    
> . instrumentation - perf data capture perhaps
>    
> . standard debugging ??
>    
> . output options - yes XML output, or more likely Locale/Nat Language 
>  
> support    
> 
> . unified test support (a common test harness for all plugins).
>    
> without cost (or much) to the plugin author and allowing the
> maintainers to deal with what amounts to a more useful implementation
> of utils.pm, _instead_ of modifying each and every plugin
> (perl -i.bak -pe 's/foo/bar' only takes one so far) to support these
> functions.
> 
> As the various advocates of this approach say, it makes life easier
> for authors by requiring them to only 
> 
> . write a function that checks the service
> 
> . set various attributes corresponding to mandatory and not-required
> options with their edit checks (personally I can live without edit
> checks), help and so on.
> 
> without having to do option processing and the rest of a plugin
> program.
> 
> If this is a bad idea, please let me know why.

I'll keep this short, as work continues to absorb most of my time.

I was and am still in favor of incorporting the changes subject to 2
conditions:

1) we should have a 1.4.0 stable release to incorporate against

2) you agree that the performance cost is acceptable.

I can try to work on #1, but as noted above, free time is presently near
zero.

As far as #2, the judgment call is entirely in your court as far as I am
concerned.

As usual, people may disagree. But those are my opinions on the matter.

-- 
Karl




More information about the Devel mailing list