<!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">
Stanley,<br>
<br>
What you saw was a first attempt to get a structural approach working.
I have since:<br>
<ul>
<li>Coded a number of other plugins to use this approach.</li>
<li>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.</li>
<li>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.</li>
</ul>
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!<br>
<br>
Regards, Howard.<br>
<br>
Stanley Hopcroft wrote:<br>
<blockquote type="cite" cite="mid20040321220415.D237@IPAustralia.Gov.AU">
<pre wrap="">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.
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<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<br>
</td>
<td style="vertical-align: top;">Phone:<br>
</td>
<td style="vertical-align: top;">+44(20)7690 7075<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">Coherent Technology Limited<br>
</td>
<td style="vertical-align: top;">Fax:<br>
</td>
<td style="vertical-align: top;">+44(20)79230110<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">33 Belgrade Road, Stoke
Newington,<br>
</td>
<td style="vertical-align: top;">Mobile:<br>
</td>
<td style="vertical-align: top;">+44(7980)639379<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">London, United Kingdom, N16 8DH<br>
</td>
<td style="vertical-align: top;">Email:<br>
</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><br>
</td>
</tr>
</tbody>
</table>
<br>
</div>
<DIV><P><HR>
This message contains confidential information and is intended only<BR>
for the individual named. If you are not the named addressee you<BR>
should not disseminate, distribute or copy this e-mail. Please<BR>
notify the sender immediately by e-mail if you have received this<BR>
e-mail by mistake and delete this e-mail from you system.<BR>
<BR>
E-mail transmission cannot be guarenteed to be secure or error-free<BR>
as information could be intercepted, corrupted, lost, destroyed,<BR>
arrive late or incomplete, or contain viruses. The sender therefore<BR>
does not accept liability for any errors or omissions in the contents<BR>
of this message which arise as a result of e-mail transmission. If<BR>
verification is required please request a hard-copy version.
</P></DIV>
</body>
</html>