http://bugzilla.spamassassin.org/show_bug.cgi?id=3217
------- Additional Comments From [EMAIL PROTECTED] 2004-03-29 08:15 -------
Subject: Re: SpamAssassin.pm: "bayes_scanner" may be undefined
On Mon, Mar 29, 2004 at 01:31:58AM -0800, [EMAIL PROTECTED] wrote:
> would require that a cache rebuild requires some message to be
> learned as a prelude to rebuilding the caches (which already
> contain many learned messages). This seems to be an unnecessary
> complication to a simple "rebuild" request.
In theory -- but when will a daemon issue a rebuild request? Conceptually
it could be advanced enough to do it when it decides is a good time to
do it when nothing else is going on, but then it'll also be advanced
enough to call init() IMHO.
All of the daemons I know of only do rebuilds when using the DB in
question, which is going to be after a learn()/check() run.
> 2. Let "init_learner()" itself do the relevant "init()"-like
> things. Possibly using within it something like either:
> $self->init(1);
> or
> $self->{bayes_scanner} = new Mail::SpamAssassin::Bayes($self);
It really needs to do the whole init() run if it hasn't already.
Otherwise the Bayes paths and such will all be unconfigured.
> Does that seem reasonable? I hope so, but let me know if and
> how that is not the case.
>
> Failing that, if we (from MailScanner: www.mailscanner.info) have
> to use a "learn", is there some way of giving "learn" some sort
> of null email, neither spam nor ham?
If you send in an undef message, learn() just aborts. I believe
everything else is set to handle the undef situation.
But if MailScanner is going to actually get into a situation where it
wants to rebuild on its own, we should be able to work something out
which isn't as hackish as the undef learn thing, but I'd like to know
what the general plan/thinking is for rebuilding w/out check/learn()...?
I'll look at the code and see what looks good. I'm not sure
init_learner() is a good place for an init() call, but it may be better
than the other available choice.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
