[Nagiosplug-devel] Access to CVS as a developer

[Howard Wilkinson]

Stanley,

What you saw was a first attempt to get a structural approach working. I 
have since:

    * Coded a number of other plugins to use this approach.
    * Started to move to a OO based library that will I hope get rid of
      90% of the additional 'code' written to manage the plugin options
      - I am looking to do more that automate the print_usage and
      print_help facilities now. Although my original motivation is
      still to output the options as a structure that can be parse
      easily by an auto-learning interface.
    * Recode the existing plugins to have a common logic flow and action
      set and where possible harmonious the flags used by the plugins to
      give a common set of inputs. - Might have to provide some
      conpatibility facilties here, which is a pain but I see as a
      necessary.

I hope to have something to look at by Wednesday this week and will send 
that through. I will then recorde all of the Perl plugins to 
thisstandard if it is acceptable and ask that the ones I cannot be 
tested locally, be tried out. I am leaving the other languages at 
present, having decided I want to get this right first. So please wait 
to see what I can do!

Regards, Howard.

Stanley Hopcroft wrote:

>Dear Gentlemen,
>
>I am afraid I don't like the look of what I see in check_apache.pl.
>
>My quick first reaction is 
>
>1 Code that is likely to be replicated in _each_ plugin
>
>2 Code of questionable utility.
>
>This is a general comment on the Nag plugin approach of rigorously
>checking options and so on. This may violate the 'be gracious with what
>you accept' policy. OTOH, it may preserve POLA. My stance is check the
>plugin specific options that matter to the plugin and let the user worry
>about the consistency and sanity of the others: the 'out of here
>approach' as used by many CGIs.
>
>There is some infrastructure in embedded Perl to trap the 'out of here'
>cases.
>
>3 An approach to providing function that I have no sympathy with. 
>
>If I am mistaken please forgive me, but it seems to me that extra
>function is added to the plugin rather than in a common base elsewhere.
>
>Would doing so in an object infrastructure or at least a procedural
>framework like utils.pm/.sh be a better approach ?
>
>This could even be done in C/C++ for performance, and other language
>bindings added (eg a Perl XS object for Perl plugins)
>
>Again, I would be delighted to have this corrected, but it seems this
>approach raises the bar or cost of entry of 'standard conforming' Nag
>plugins, since plugin authors are expected to do more than they are now.
>
>Lastly, I don't expect these remarks to be taken seriously for obvious
>reasons (lack of effort, understanding, ...) but I am concerned that
>effort is being made to provide really good useful features in a way
>that I won't be able to or choose not to - code bloat reasons - take
>advantage of.
>
>I hope this is _not_ what you are proposing, but I can't see any of the
>words that I have found promote reuse and reduce both development
>and maintenance effort, namely 'class/object' and or 'library/useful
>routines'. In my practise, unprofessional and stupid that it is, I have
>always ended up rewriting procedural interfaces - or living with the
>drawbacks - but can keep on copying constructor and method calls, even
>for second rate classes with interfaces that suck, till the cows come
>home.
>
>If I have misunderstood, I apologise. 
>
>Lastly, your effort and plans impress me no end. Well done ! But I don't
>want my plugin output in XML, I think.
>
>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.
>  
>

-- 
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/20040321/2480246e/attachment.html>