Hi,
--On Sunday, July 28, 2002 12:45 PM -0700
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
|> Are implementations likely to have multiple spam filter algorithms
|> available? If so, would it be worthwhile to allow you to choose one
|> dynamically?
|
| It's possible, I guess. A testtype parameter might be appropriate. Its
| argument could be compared against the list of available schemes. In the
| case of no match a default scheme would be used.
The problem with this is that the script author needs to know what
implementations are available on the system.
That's why I suggested falling back to a system default if the specific
requested service isn't there. I suppose this could be generalized into a
preference list or something, but OTOH I really don't expect systems to offer a
wide variety of such services.
I really wanted spamtest to be
completely independent of the backend spam checking so scripts could be
simple and portable. If there is more than one spam checker in use, then I
think spamtest results will simply be based on some combination of the two
(or more) sets of spam check results - and the sieve implementation would
be smart about figuring that out. If a user really wants finer grained
control then they can write the spam tests explicitly in the script rather
than use spamtest.
That's fair, I guess. This certainly isn't a must-have for me.
Ned