On Fri, 2 Jan 2004 00:37:49 -0600, Bob Apthorpe wrote:
> - it's not clear who would maintain the SA<->external code
> interfaces
Somehow, the logical thing to me seems to be more generic.
Put a generic "call external application" hook into SA. This "hook" could be simply a
definition of an interface that user functions must conform to and of how to tell
spamassassin to call them.
The user function could be something as simple as this:
sub user_function_with_a_better_name_than_this($) {
my ($path_to_raw_mail_file) = @_;
# Do your stuff here, calling bogofilter, checking for PGP keys, sending
someone for pizza or whatever
return ($was_a_hit,$hook_name);
# or, for more complex stuff: return ($was_a_hit,$hook_name,$flags,$exact_score);
}
The "hook_name" is of course the name you use in rule definitions.
An alternative but also more complex way could be that user extensions need two
functions. Like this:
sub register_sa_user_function { #allways has this name, there has to be a separate
file for each user extension
# returns the rule name and what kind of data we wants to work on. The data
types could be something like:
# 'file', a path to the actual mail file.
# 'body', the body in memory
#' you can guess the rest.
return ('MY_USER_FUNCTION_RULE_NAME','file');
}
sub sa_user_function($) {
my ($mailfile) = @_;
# call bogofilter or whatever
return $was_a_hit;
}
With a hook like that, the SA devs doesn't have to maintain the interfaces to the
external apps. They just have to maintain the much smaller code calls user functions
and (as with all such interfaces) should change as seldom as possible.
This later thingy also allows users do add quite a lot of extensions without having to
patch the SA code.
This can lead to problems if the users of SA are uncareful, but it also places that
responsibility on the users instead of the devs. And if a user comes up with a very
good and popular user_function, it can easily be included in later releases of SA with
that user as maintainer for that separate extension. :-)
Note: I do realize that one could expand the above thoughts to a very complex and
flexible plugin system where the user functions can call a number of interface
functions and whatever, but that'd create a lot of work for the devs. Personally I
feel that a rather limited, simple, but usefull interface is more likely to actually
both be implemented and work in reality.
This is actually something I *might* look at doing myself. :-)
Regards
/Jonas
--
Jonas Eckerman, [EMAIL PROTECTED]
http://www.fsdb.org/
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
