Front page | perl.qpsmtpd |
Postings from June 2012
From: Matt Simerson
June 29, 2012 16:48
Message ID: 31B620DC-82DA-45D2-88FD-01C1181522A0@tnpi.net
On Jun 29, 2012, at 1:53 PM, David Nicol wrote:
>> Calling all forks.
>> If you have a fork of QP and would like to become much less forked, or perhaps even be able to use QP without being forked at all, this would be a great time to bring out your fork.
> Should one add plugins? Perhaps as placeholder files referring to
> where to get the genuine article, to reduce the possibility of naming
Using placeholders is one way to avoid collisions.
Another is to have a plugin registry, like this one: https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/registry.txt
The aliases field in the plugin registry provides historical clues as to what happened to older plugins, or what they evolved into. For example, the current 'badmailfrom' pattern came from merging the check_badmailfrom and check_badmailfrom_patterns plugins. A user looking for check_badmailfrom could see that plugin is now badmailfrom, and could read the POD for more details. That's one use of the registry. The reason I added the registry is so that my log parsing plugins could recognize the types of log entries, and bark loudly when they encountered entries they don't recognize.
Another way to avoid collisions is to include all the plugins. It costs very, very little to include a plugin. Even a less than great one. Then every plugin has a canonical name, a home, version tracking, and plugin discoverability is easy. For plugins that have very little "general" appeal, we could create a rummage bin within the repo, so they're out of the way, but still easy to find, reference, and use.
The current plugin situation, with a half dozen incomplete plugin lists, and plugins hosted all over, and many URLs suffering from bit rot, is a poor solution. Having all the plugins in one place would spare developers from reinventing wheels, users from STFW to find them, and Big Picture document authors a lot of research. Having all the plugins in one place is great for users. We've seen this already with Wordpress, App Stores, and CPAN. Get 'em all rounded up in one corral, and when they get unwieldy, we can work out a solution for managing them.