Hi Lloyd,
> Although the various filtering tasks that I perform within my modules
> are mostly independent of one another, sometimes the result of one
> filtering action can affect what I want to do within a subsequent
> filter.
>
> [...]
>
> I came up with a way to do this (see below), but it's a hack, and I'm
> wondering how feasible it would be to enhance Courier::Filter so that
> there is a more formal mechanism for sharing state among the various
> calls to the filter modules.
Yes, your solution indeed is a hack. ;-)
Your %state structure is actually a global variable, which may not be
thread-safe in future, thread-enabled versions of Courier::Filter.
Luckily, there's a better solution. Thanks to Perl's liberal nature, you
are free to store whatever message-specific information you like in the
$message object (it's a hash) passed to each filter module. Just be sure
not to overwrite any Courier::Message-reserved hash keys. I suggest
prefixing the key names you use with a unique string, e.g. the filter
module's class name. Overall, it could work like this:
| # You'll need to modify the original SPF module:
| package Courier::Filter::Module::SPF;
| # ...
| sub match {
| # ...
| $message->{SPF_result} = $result;
| # ...
| }
...and:
| # Your own module that wants to use the SPF result:
| package Courier::Filter::Module::MyFilter;
| use base qw(Courier::Filter::Module);
|
| sub match {
| my ($module, $message) = @_;
| if ($message->{SPF_result} eq 'pass') { ... }
| # ...
| }
This is the best one can do with Courier::Filter 0.12. However, this is
not the most elegant solution ever, since a MyFilter module could depend
on the results of a specific instance of a (for instance) DNSBL module, of
which there might be more than one instance in a single Courier::Filter
setup -- so the various DNSBL modules would overwrite each other's results
in the $message object, and which result would then get used by the
MyFilter module? So in the general case, this solution is still a mess.
In general, you should try to avoid direct interdependencies between
filter modules in cases where your needs can be satisfied by forming
somewhat complex filter module groups (see the "modules" option of the
"new" constructor in Courier::Filter). There are not just *linear* chains
of filter modules, filter module groups can be trees (i.e. recursive),
too.
Future Outlook:
Thanks to your feature request, I will add to a future version of
Courier::Filter the possibility to give filter modules unique names in the
configuration file (i.e. "DNSBL/Dynamic IP Addresses", "DNSBL/Spam",
etc.). These unique names may then be passed as configuration options to
other filter modules, which then (through an extension of the
Courier::Message interface) may query the $message object for the results
of *specific* instances of filter modules.
To hammer out this model, it would be helpful if you could provide some
real-world use cases (that cannot easily be implemented through somewhat
complex module groups) for reusing results of prior filter modules.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
