> > I suspect there's a happy medium.
> Except for the fact that you cannot disable a loaded plugin later on,
> for example, enable spamassassin for all, but disable it for authed
> clients without a fixed ip or network would not be easily possible
> (without duplicating nearly all code from this plugin or a plugin
> rewritten with the upcoming changes). With my changes you can have a
> simple plugin like
>
> sub hook_data_post {
> my $self = shift;
> $self->disable_plugin("spamassassin")
> if $self->auth_username;
> return(DECLINED);
> }
>
> to do this. Configuring the plugins this way, and not loading nothing
> and probably enable them later on, is easier IMO.
Hence my suggestion for the pluggable plugin dispatch loop.
I just don't want the core cluttered with things that only 1% of users
will use.
What methods do we need to add to the plugin class? I think some of
them were in your patch.
- plugin_enable, plugin_disable - could be the same method
- plugin_list - list all plugins, maybe a verbose version too
- plugin_name_normalize - do the weird name hashing stuff
with just those in core, a connect plugin could do the appropriate
toggles without changing the plugin dispatch loop
an outstanding question is what's the scope of plugin_enable/disable.
Of course- you don't need any of this at all right now to do what you
need.
You can write a plugin wrapper plugin and load it multiple times.
wrapper dnsbl
wrapper plugin1
wrapper queue/postfix
and the wrapper plugin has all the logic.
-R
