On Sat, 06 Jan 2007 23:40:27 -0800 Robert Spier <[EMAIL PROTECTED]> wrote:
> > Please see my "peers" plugin posted a few months ago > > (http://www.nntp.perl.org/group/perl.qpsmtpd/4475). It allows > > different (arbitrary) sets of plugins to be hooked for different > > ranges of connecting IP addresses, and required no code changes in > > core (or in other plugins). > > > > I said then "I'd appreciate some feedback", and that remains true > > today :-) > > And now you'll get some. > > General comments: [...] > - I like the implementation, it's nice and clean (minus the small > amount of duplication.) (and one is broken now, plugins are just loaded from a single directory). > - It only works with networks configured on 8 bit boundaries, but in > practice this probably isn't an issue. Not? It's more common not to "own" a /24 or /16 IMO. With these 8 bit boundaries I'd have to add several /26, /27 to a list... every single IP. [...] > - The configuration interface is somewhat rough - requiring multiple > on-disk records. (aka filesystem as database model). Since they > can mostly be symlinks, thats probably not a huge deal. (I'm > waffling over whether I'd prefer a file based configuration > method.) Chosing something like in 'skip_plugin' or 'hosts_allow' deals with this and non 8 bit boundaries ;-) One thing which I don't like is to have the plugins which are loaded in another config file (next to plugins, logging). What happens if a plugin is set in a clients plugin list, but not in the peers plugins config (i.e. not compiled at startup)? Can I give arguments for a plugin? > Based on your replies to Ask's comments > (http://beta.nntp.perl.org/group/perl.qpsmtpd/2006/02/msg4497.html) > > it looks like we need to factor out some of the functionality for > plugin loading, and an API to be a little more versatile for it. > > I think that's where some of Hanno's change comes in. He started > building some framework for that. > > 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. Hanno
