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
> collisions?


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. 

Matt

Reply via email to