http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
------- Additional Comments From [EMAIL PROTECTED] 2005-01-15 22:31 ------- Subject: Re: [review] Feature Request: whitelist_subject and blacklist_subject > I don't really want to have 17 bajillion plugins in the standard dist. > > If it's really useful, put it in the main code. If it's useful, but > possibly/likely to be disabled by a decent number of people, make it a > standard plugin. If it's useful for some, but not most/all, just put > it up on the wiki as a plugin people can install themselved. Let me suggest a differrent viewpoint, based on the concept of sites where there is a central administration (who are the only ones that can install plugins and enable them, currently) and users that might be able to write their own overrides and possibly rules (if allow_user_rules is set). While this isn't a popular configuration with the developers, there seem to be a fair number of sites that do work this way. Even with allow_user_rules, a user can't use plugin functionality if the plugin isn't there. In fact, they can't even use the plugin if it is there and wasn't enabled site-wide, currently. As more stuff moves to plugins (as it likely will), this degrades the concept of allow_user_rules, and possibly even individual user config options, if the plugins haven't been installed or enabled by the central site administration. It appears that currently plugins, along with their register_xxx functions, can do almost anything internal code can do, and possibly do it just about as efficiently. It therefore strikes me as likely that a lot if internal code will probably start getting factored out into plugins just to simplify the code and make it more readable. Thus, per-user rules and options are likely to become less capable with time as more stuff migrates to plugins, especially if all of the plugins are optional and/or not enabled by default. Based on that, I would be inclined to include the widest possible number of plugins in the base release, so that the widest possible number of rules are potentially available, even on a decentralized site with centralized infopriests in charge of enabling options. I would also look at the idea of either having all found plugins enabled by default, or possibly enabled unless a central disable option was present, or optionally enable-able by jive users in individual user configs. (There might be a central option to allow users to enable plugins. In fact, allow_user_rules is already a central option that would fit that purpose.) So I would be strongly in favor of including the maximum number of known-working plugins with the base and patch releases. If the plugin isn't enabled, nothing is lost but a tiny amount of disk space. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
