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. 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.
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:
1) One of the core developers must become an advocate, usually through a
persuasive argument that the feature is worthwhile adding;
2) The feature must be generally useful (in the minds of the core developers at
least), especially if it increases the complexity of the code;
3) The feature should be narrowly targeted (by which I mean a larger change is
harder to validate as being correct than a small change);
4) The core developers all lead full and rewarding lives, which inevitably leads
to not having that much time to dedicate to any one project.
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). 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. 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.
Coding on the fly, consider having a single dispatcher plugin for each hook,
acting as a gatekeeper for the individual plugins, which would just depend on
the hook dispatcher to handle the common preliminaries. It would mean that
there would be logic in one place to decide whether a given plugin should get a
shot at the message. In the global configuration case, this dispatcher would do
nothing; in the per-recipient case, it would compare recipient to the master
list and only fire the plugins which were set. This would only require
abstracting out the existing plugin loop from the core and allow it to be
pluggable.
John
