[Spambayes] Some more experiences with the Outlook plugin

[Mark Hammond]

> [Paul Moore]
> > * Following on from this, I also see Tim's behaviour of surprising
> >   unsure cases (or worse, false negatives!). Worst case recently was a
> >   message which scored as solid ham. I trained on it as "Spam", and
> >   rescored it. It still scored 5 - solid ham.
>
> [Mark Hammond]
> > This too was my experience.  For a while, I did training over a huge
> > ham corpus, and spam is still less than 1000 messages.  I had around
> > 15:1 ham:spam.  I too trained new ham and spam, and was dissappointed
> > to see the score remain almost identical.

> Almost identical or exactly identical?

Almost exactly identical <wink>.  I can't recall for sure, and wasn't
actually playing with bayes - just sorting through mail before trying to do
something productive.  I'll get back to playing with this stuff, but only
after I get back to the client itself <frown>.

> still heavily hapax-driven teensy classifier, the auto-rescore feature of
> the Outlook client never seemed to change my scores either, and for a
> hapax-driven classifier that's bizarre.  It turns out that was because it
> actually didn't change scores:  the probabilities didn't get updated after
> training on the reclassified msg, so "the new score" was in fact exactly
> equal to "the old score".  I just checked in a fix for that (unique to the
> Outlook client).

Hrm - I could have sworn I saw the scores change in quite a few cases.  But
as I said, this is hardly a controlled environment.  You should see my desk
<wink>.

And to compound things, I am seeing messages I don't understand from my
"delete as spam/recover from spam" functions - I suspect they are broken as
I see "already trained as spam" when, eg, training a new unsure as spam.
Quickly eyeballed the code and it looks OK - haven't debugged yet.

> So it would be good to retain the old database for concurrent scoring
> purposes until the new one is ready to use, or it would be good to delay
> scoring msgs until training is complete.  I've refrained from "doing
> something" about this because it seems like it would be easy to do after
> some mechanism is in place for scanning for unrated msgs at startup (i.e.,
> folder events could be disabled for the duration of from-scratch training,
> then re-enabled after, and the scan-for-unrated machinery kicked
> into action
> again).

Well, threads wouldn't be a bad infrastructure to use <wink>.  Extended MAPI
is documented as being thread-safe (which, of course, may just result in
serialization).  I understand that we still have the same issue with a full
re-train, so I only mention this to ask if now is also a good time to
implement our own locks or threading strategy.  In the very least, it
couldn't hurt to spin off the pickle loading, and anywhere else people
complain we hurt (eg, future bulk deletes or moves, etc)  A simple queue
would even suffice - not much needs to be synchronous at the moment, if
anything (assuming asynch usually means "almost synch" <wink>).  Asynch
message filtering wont fly in the lower-level message hooking functions we
are eyeballing though :(

Outlook itself certainly does plenty in the background (and currently shows
14 threads for me).  Eg, the unread message counts in the folder view and
"Outlook Shortcuts" panes can take a few seconds before they show up (during
which time Outlook is running just fine)

Mark.