This is a clever approach.

That said, why are you so concerned about extending your program's behaviour without modifying the code? (That's a question, not a criticism.) It seems to me that being able to extend a program without adding code is most useful when the program takes effort to re-package (for instance, the familiar compile-link step with C), or when the code itself is difficult to modify. Perl avoids the first issue -- just edit and go. The second will become a problem no matter how you're extending the program.

If you have a block that looks like:

&check_proc('ldap -p 389', 'LDAP is not running', 'medium');
&check_proc('sendmail: accepting',
            'sendmail is not accepting new connections',
            'major');
&check_proc('/xntpd', 'NTP daemon is not running', 'minor');
&check_proc('apache/bin/httpd',
            'Apache web server is not running',
            'minor');

[download]

it doesn't take much more effort to add another call to check_proc than it does to modify a config file, and if you ever want to do something different (like monitor system load), you're set: you won't have to add syntax to the config file for a different kind of check, just add another sub. Never mind that you've eliminated a goodly chunk of code (the config file parser) and another feature (reading config files), which won't exactly make your code more difficult to maintain.

The only disadvantages I can see are:

  1. Depending on how your monitoring script is running, it may be more difficult to refresh the code than a config file.
  2. It'll probably be more difficult for other people to change the code than the config file, especially if the code has appropriately strict permissions.

but these may not be of concern to you.

Keep the code loosely coupled, write solid unit tests, and code becomes easy to change. (At least, that's what the eXtreme Programming zealots would have you believe... and in my experience, they're on to something.)

Good luck, and let us know how it turns out. I wouldn't mind seeing this appear in the Code Catacombs.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

In reply to Re: Anticipation of future needs and other musings from the crystal ball by FoxtrotUniform
in thread Anticipation of future needs and other musings from the crystal ball by Limbic~Region

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.