Removing pickle support from Outlook? (wasRE:[Spambayes]Lostdatabase)

[Mark Hammond]

> > Yes, this is the "None" return val.  All cases had:
> > > >    return None, True or False
> > What did you think I meant?  None = not known, result = result :)
>
> Well, None could have been unsure (see my previous message).

Right, yes, I missed that.  Do we actually need to know the classification,
or just the score?  But yeah, maybe one extra method.

Outlook has no need for the "classified" portion of this database, only the
"trained", but that is OK.  Actually, I *might* use the classify database -
it may help with read-only stores, such as hotmail.  The "if I have already
seen this message, don't filter it" smarts are likely to fail for hotmail.
Not that I have a clue about hotmail.

> The more I consider it, the more I think that an ID shouldn't be able to
> change.  If IMAP needs to assign a new id, it can create a new message.
> Hopefully others won't need to (Outlook ids are meant to be permanent,
> right?).

They change when you move a message to a new folder.  I can see how it is
handy to say "this message has changed ID" and have the database updated
accordingly - but I can't see why SetID can't do it.

OTOH, Outlook uses the "conversation id" (iirc) rather than message ID for
this database just to cope with that fact.

> This definitely should be a "header-enabled" sub-class.  Pop3proxy,
> IMAP, notes and maybe hammie (don't know much about hammie) can use
> this.  'Real' integrations like the Outlook plugin can go their own way
> after taking the base class.

I dont see that I need anything beyond the base class - just a handful of
"remember this" and "get this" methods passing an ID I have already
constructed.  But yeah, that is right.

> > Any assumptions about IDs, other than that
> > they are strings and that they may change over the life a
> > single object similarly.
>
> Should an id be able to change over the lifetime of an object?

Obviously this is easy to work around by an application - just "unremember"
the old message ID, and remember the new one.  If this makes life easier I
am happy for it, but I don't think Outlook would use it - Outlook changes
IDs on message moves, and the user can move whatever they like without us
able to track it - so yeah, Outlook needs an immutable ID.

> > When I find some more cycles for spambayes I will have a play
> > with whatever is in CVS at the time.
>
> If I find time today I might do some of this since we're testing with
> IMAP at the moment.  Putting it all together into one bsddb3 database is
> all yours, though ;)

Deal ;)

Mark.