[EMAIL PROTECTED] (Justin Mason) writes:
> - (b) hack at Mail::SPF::Query to support async event polling.
>
> - (c) hack at Mail::SPF::Query to use the shared DNS cache. Both
> of these will probably require us making a
> Mail::SpamAssassin::Plugin::SPF::SPFQuery class -- our own
> copy of M:S:Q.
I'm not in favor of making our own copy of Mail::SPF::Query. It's still
a moving target.
I think we'd be better off making changes to Mail::SPF::Query so that we
can continue to use it and get those accepted into upstream. Maybe
something like we a way to the queries and feed the results into
Mail::SPF::Query for analysis.
At least, I think we need to think about it before we go down the deep
hole of maintaining an SPF module.
> start_lookup() {
> my ($self, $type, $bgsendargs, $done, $state) = @_;
>
> type: string representing the lookup type, e.g. "URIBL", "DNSBL",
> "SPF" etc. Important so we can identify and kill lookups
> for a particular subsystem if they're taking too long,
> without killing all other lookups.
>
> It may be appropriate to use a numeric type here, although that
> would mean that future plugins would need to reserve new numbers
> (a bad thing).
We *could* make a dynamic mapping from names to numbers. Arrays are
cheaper and smaller than hashes and make sense when you don't really
need a hash. I'm not saying that's the case, just that a dynamic
mapping might work.
> $bgsendargs: ref to array of arguments for the $res->bgsend() fn.
> Also used (in stringified form) as key for {activelookups}
> hash.
What about order of arguments?
> if $self->{activelookups}->{$bgsendargs} does NOT exist, a new
s/activelookups/active/
Same question about order of arguments and stringification of
$bgsendargs.
> subhash $self->{activelookups}->{$bgsendargs} is created with a
> sub object $self->{activelookups}->{$bgsendargs}->{$type}, and
> $self->{activelookups}->{$bgsendargs}->{BGSOCK} =
> $res->bgsend($bgsendargs), then this method returns.
->{$type} and ->{BGSOCK} might be a good place for an array.
use constant BGSOCK => 0;
use constant TYPE => 1;
->[TYPE]
->[BGSOCK]
> count_lookups_of_type ($type)
> count_lookups ()
>
> Return how many lookups are remaining in that type.
> This allows dynamic timeouts a la Dns.pm.
We'll also need to know how many lookups were started.
> That's basically it. I think that should cover all the needs
> of SPF, Dns.pm and URIBL lookups. comments?
I'm still very concerned about the CPU overhead and I'm now somewhat
concerned about the very significant additional complexity. It may
really make more sense to roll everything into the (yes,
high-specialized) Dns.pm code and also not use any plug-ins for this.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
