You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/01/25 05:36:49 UTC

plugin design Q: reading rules code from plugin .pm's directly

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Justin Mason writes:
>1. define a local eval rule, "DUMP_URIS", like so:
>
>	loadplugin DumpUrisPlugin /path/to/dumpurisplugin.pm
>	body DUMP_URIS	eval:dump_uris()
>
>2. create a simple plugin module that registers an eval function
>for that, dump_uris(), which would look like this:
>...

hmm -- thought -- would it be worthwhile having semantics for .pm files in
the rules directory be directly read as plugins; we could then embed the
rule definitions like those above into a well-defined section of the POD
doc.

e.g.

  =head1 NAME

  FooPlugin - plugin to do foo

  =head1 SYNOPSIS

  ....

  =head1 RULE CODE

    loadplugin		FooPlugin	[needed to know module name]
    body FOO_RULE_A	eval:foo_a()
    body FOO_RULE_B	eval:foo_b()
    body FOO_RULE_C	eval:foo_c()
    tflags ... etc.

  =cut

  ...perl code...


This would avoid the need for 2 files for every plugin, one for the
perl code and one for the SpamAssassin rules code to load it.

The SpamAssassin rules-file parser would just have to know that
in a .pm, only the =head1 RULE CODE pod section is parsed.

thoughts?

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAE0fhQTcbUG5Y7woRAtSGAJ9VkpSKMmxG1nTD7kIA66F/mmPIHQCfSNjz
HoLlEIOhQLgHay1qXRXXlwg=
=evri
-----END PGP SIGNATURE-----


Re: plugin design Q: reading rules code from plugin .pm's directly

Posted by Theo Van Dinter <fe...@kluge.net>.
On Sat, Jan 24, 2004 at 08:36:49PM -0800, Justin Mason wrote:
> This would avoid the need for 2 files for every plugin, one for the
> perl code and one for the SpamAssassin rules code to load it.
> 
> The SpamAssassin rules-file parser would just have to know that
> in a .pm, only the =head1 RULE CODE pod section is parsed.

hmmm.  how about letting the plugin inject the conf via an init_conf()
call or something?  That way we don't have to read another file (and
deal with the parsing), and you still get the benefit?

-- 
Randomly Generated Tagline:
"sendmail is a big cloud of murky sysadmin magic ...  I'm still an
 apprentice."                             - Theo