Re: spam.el: generic bayes interface?

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 20 Jan 2004, hubert@uhoreg.ca wrote:

> Well, there are at least some good reasons that someone might want
> to use multiple Bayesian filters.  For example, one might want to
> just try out the effectiveness of one filter, while retaining their
> original filter as a backup.  Also, if one wishes to switch Bayesian
> filters, and does not have a corpus of spam/ham to train the filter,
> there would have to be a transition time during which the new filter
> is trained, while the old filter is still being used for splitting.
> And, of course, during this time, one would still want to keep
> training the old filter at the same time.

I'm OK with that, we can add a spam-use-generic-bayesian if it's
necessary.  I just think customization, registry tracking, and other
things won't work so well when we generalize the interface too much.

If you or someone else produces that generic-bayesian backend, I
don't see a problem with putting it in.  We can't anticipate the new
bayesian filters people might want to use, after all.

> This got me thinking, though, Ted, that the registration code for
> the spam/ham processors is pretty similar.  They seem to mostly work
> in one of two ways -- either register one at a time, or register
> multiple articles at a time in a mbox-style format.  

Yes, I've noticed that too after the 3rd time I wrote that code :)

> I think they all feed the articles via standard input.  I would
> imagine that we would be able to share a lot of common code.  Maybe
> write a function that feeds the article(s) to the registration
> program, and pass the name of the program and its arguments as
> arguments to that function.  Then the registration functions just
> have to call that function with the appropriate arguments.  Hmm.
> I'll have to look at the code to see if that would actually work...

It could work.  I've been trying to make the functions generic on the
API side, now it's time to make them generic on the backend side as
well.  I'm afraid it will make the code more complex, but adding new
backends should be significantly easier.

I'll work on gnus-encrypt.el first though, so feel free to start on
this if you have the interest :)

Thanks
Ted