[Nagiosplug-devel] Perl plugin architecture/principals: not one but _two_ OO bases.

Stanley Hopcroft Stanley.Hopcroft at IPAustralia.Gov.AU
Thu May 13 02:15:02 CEST 2004


Dear Folks,

Since Mr Howard Wilkersons heculanean effort to rewrite all the plugins
using basically a plugin specific check method of a Nagios::Plugin
class, Mr Yuval Kogman has proposed a completely independent and
different OO implementation for Perl plugins.

These classes provide

. standard help - an attribute set by the caller plugin

. standard/uniform option processing

. a vastly simpler means of creating Perl plugins

. public interfaces (for future GUI configurators) that publish the
plugins signature, options, usage etc (ie some elements of
introspection)

. standard means of exporting/capturing perf data

. standard means of exporting/producing plugin output - presumably for
input by other tools

My position of valuing plugin performance above ease of construction, 
and undervaluing the bits that I don't use right now (espesh the perf
data) is slowly being eroded by the enthusiasm and energy of these
gentlemens work, and the keen desire not to lose their contributions.

What is the way forward ?

1 Maintaining not one but two or three versions of the same plugin

2 Publishing the OO frameworks CPAN and public notification of the
CPAN plugin alternatives

3 Adopting one of the OO frameworks and rewriting the Perl plugins

4 A Perl OO plugin XS ( in C++ sheesh ...)

5 Continuing as is

6 A better idea than 1 .. 5

6++ Wait for P6 (coming real soon now) - where performance is 'fixed';
at least for small values of 6 (see Apocalypse 12 on Perl.COM.  Noting
that the embedding interface for the P6 virtual machine is the subject
of some vituperation at the moment; the controversy seemingly about the
prospect of the embedded interpreter being garbage collected
prematurely).

There is simply _no_ way that the OO frameworks will provide as good
performance as the existing procedural plugins: the method despatch
overhead is too large, and P5 subroutines/methods are slow. ePN will not
help OO based plugins catch up since the slowness is not in the
compilation phase.

However, both Howard and Yuval are using them in production and
are obviously pleased with them and developing accordingly.

'one more object for ePN to cache and store,
 one more object for ePN to leak more core,
 and if one more object should accidentally be constructed,
 there will be aleph 0 + 1 pages thrashing out of store'

(tune of 'aleph 0 bottles hanging on the wall')

Yours sincerely.

-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.




More information about the Devel mailing list