(Side note, John, your newsreader is not doing nice things to the mail
headers.)
> Funny, I thought that was what regexes were for... ;)
regwhat?
> > - We teach plugins to record things.. so spamassassin could do
> > something like $qp->transaction->notes( 'stats_spam' => 1 ); or
> > something.
>
> That is, of course, the weakness of this method: all of the plugins
> have to be modified. As an interim solution, why not have run_hooks()
> always add a bare minimum (plugin name, result code) into the
> ->notes(). The key would then need to be the plugin name:
>
> $qp->transaction->notes( 'spamassassin' =>
> { return => DECLINED, } );
I like this.
> On the other hand, if the plugin desired to create an entry, it would
> store it's information in a hash:
>
> $qp->transaction->notes( 'spamassassin' =>
> {'hits' => 16.5,
> 'tests => 'FORGED_RCVD_NET_HELO,FROM_ENDS_IN_NUMS,HTML_30_40',
> }
> );
>
> and the default return would be added to the hash by run_hooks.
And this.
> Finally, the transaction_end hook would split that out as three columns:
>
> PLUGIN ATTRIBUTE VALUE
> spamassassin return DECLINED
> spamassassin hits 16.5
> spamassassin tests FORGED_RCVD_NET_HELO,...
>
> How's that sound?
Beautiful!
Almost. :)
There's a namespace issue, because there are potentially multiple
results from multiple callbacks.
$self->transaction->notes( $code->{name})->{"hook_$hook"}->{'return'}
is what i've implemented and checked into trunk
now we slowly augment the plugins. We may still want to change the
structure a little.
-R
