On 2006-07-16 10:12:33 -0400, John Peacock wrote: > Peter J. Holzer wrote: > > Same here. Unfortunately the qpsmtpd community seems to be quite > > affected by the NIH (Not Invented Here) syndrome. Quite a bit of > > functionality get reinvented over and over again. > > I don't think this is a fair characterization of the situation.
Sorry, I didn't want to step on anybody's toes. And I do take part of
the blame: I started a directory of available plugins once but didn't
maintain it diligently enough to be really useful. And I know I'm
frequently suffering from NIH syndrome myself.
> Historically, there has been some amount of reinvention caused by a
> lack of a central location for user-submitted plugins. The presence
> of the wiki is addressing most of that, and the ./contrib directory is
> also intended to act as a long-term repository of plugins/patches that
> are not added to the official distro.
Yup. The wiki is great and I do hope that contrib directory will be used
by plugin writers (currently there's only stuff by Hanno and me there).
> One of qpsmptd's biggest strengths is the plugin model, which allows localized
> changes by anyone with a little Perl experience. But when changes involve the
> core code (like your suggested per-recipient configuration), it has to
> overcome
> several obstacles to get applied:
[...]
I am aware of these, and that's ok.
Actually, since Qpsmtpd::Address is a hashref, any plugin could just store
and retrieve arbitrary information in it. But that's ugly and violates
OO principles, so I wouldn't propose that as a general solution.
> Personally speaking, I kind of like the idea of per-user configuration, even
> though I would probably never use it in-house (I am strictly operating in a
> corporate setting, so my configuration is imposed from above).
Well, our corporate policy is to leave such details to the user :-)
> But I have strong reservations about going through the considerable
> pain of updating existing plugins to use a new functionality unless
> there is strong evidence that the chosen method is the best one
> available (so we won't have to go through the whole process again
> later).
>
> What I'd like to see is a way to make the change more modular, so that
> duplicated code could be kept to a minimum. I don't like the idea of adding
>
> return DECLINED unless $rcpt->config('XXX');
>
> to 15 plugins if there was a better way.
For this simple case it can be probably be done with a wrapper plugin,
as Robert suggested or the dispatcher you describe below. But consider
for example a spamassassin plugin with user-definable thresholds. This
has to run in the data_post hook, which is called once per message, not
once per recipient. So the plugin itself must loop over all recipients
to retrieve their individual thresholds.
Or am I missing something?
> I strongly want to have something in place so that sites _not_ running
> the per-recipient mode don't have to do anything at all, and that
> sites that _are_ running per-recipient hooks only have to create the
> config file mapping recipient to plugin.
ACK. My code snippet was incomplete. Actually it checks whether per
recipient config is wanted before checking the config of the current
recipient. So the sysadmin doesn't have to do anything special. It does
increase the duplicated code, though (it's four lines instead of two for
the simple "is this plugin enabled for this recipient" case).
hp
--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | [EMAIL PROTECTED] | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
pgpuAKfO6XxSQ.pgp
Description: PGP signature
