On Sat, Dec 20, 2003 at 01:32:12PM +0100, Peter J. Holzer wrote:
> On 2003-12-20 22:16:52 +1100, Gavin Carr wrote:
>
> Yup. In my modified denysoft_greylist plugin, support for recipient
> options has to be explicitely turned on.
So what does that look like in the plugin?
> > A concern I have with going down this direction is that we're going to
> > then have *three* possible places plugins can source their config data -
> > config/plugins arguments passed into register(), config files accessible
> > via $self->qp->config, and your new recipient options. This is going to
> > confuse people (if it doesn't already).
>
> Maybe we can hide this behind an API? Something like
>
> sub config {
> my ($self, $transaction, $option) = @_;
>
> return
> $transaction->notes('recipient_options')->{$option} ||
> $transaction->notes('sender_options')->{$option} ||
> $transaction->notes('host_options')->{$option} ||
> $self->qp->config($option) ||
> $self->{register_args}{$option};
> }
>
> This would allow setting default values via config/plugins or
> $self->qp->config, and they could be overriden on a per transaction or
> per recipient basis. A plugin would then just call $self->config to get
> the value and (normally) not care where it comes from.
Yes, this looks much nicer to me, and is better on an implementation
hiding level for plugin authors. You're going to have some issues with
data normalisation, since $self->qp->config normally returns an arrayref,
I think, and your recipient_options sound like they're returning hashrefs,
but I think the basic approach is right.
> > Another thing is that this doesn't look terribly maintainable for larger
> > size lists - whitelists, for example, can get pretty long pretty fast,
> > but they're just the kind of thing I want to be able to customer per-user
> > or domain.
>
> Are you worried that retrieving the complete whitelist for a single
> recipient from a file or database and storing it in a perl variable is
> too slow and/or takes too much memory? In that case you just store a
> reference to a tied hash in the note.
I'm more worried about the user-editing side of this with large files and
special syntax to get right - but again this is on the config-format side
not config-use.
Cheers,
Gavin
--
Open Fusion P/L - Open Source Business Solutions [ Linux - Perl - Apache ]
ph: 02 9875 5032 fax: 02 9875 4317
web: http://www.openfusion.com.au mob: 0403 171712
- Fashion is a variable, but style is a constant - Programming Perl
