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

[Mark Hammond]

> >* setIdFromPayload(), addSBHeaders() and delSBHeaders() look
> > suspect for the base class.  If you intend splitting it later,
> > you should consider doing it
> >earlier - it will force you to face certain decisions.
>
> Where would you suggest we put these?  As functions somewhere?

As I said, "suspect for a base class".  Thus, I suggest you put them in a
sub-class <wink>

The abstract interface needs not much more than an ID, and methods to
remember state.

> my taste.  This is a typical key change kind of problem.  I'm
> kinda not sure it really matters much.

I'm not sure what a "key change kind of problem" is, but yeah, it doesn't
matter much, but we may as well make it clean from the start.

> >* should copy() do something with the id, such as reset it?
>
> Presumably, the message that is being copied into already has an
> unique id
> set, or will at some point.  This is more like a clone operation, an
> adaptation for the imap filter, which cannot simply modify a
> message.  It must
> create a new message, with a new id, and store it, then delete
> the old one.  A
> copy (clone, whatever) operation facilitates that process.

Maybe this needs more thinking through.  I assume a standard Python copy is
not suitable?  Either way, the semantics should be clear - Outlook has the
ability to copy a message, and also to "clone" a Python object.  Copying a
message changes its ID, as does moving a message.  I really don't know what
Outlook should do for clone.

> >* All the "isCls" and "clsfy" methods, and training versions are suspect.
> >If they are implementation specific, put an underscore, but to
> me they look
> >like noise.  Why not just:
> >
> >  GetSpamClassification(self):
> >    return None, True or False
> >  RememberSpamClassification(self, isSpam):
> >    void
> >  GetSpamTrained(self):
> >    return None, True or False
> >  RememberSpamTrained(self, isSpam):
> >    void
> >
> >You have about 80 lines expressing what I believe can be done in
> 10 (or so
> ><wink>)
>
> I'm not wedded to this portion of the interface by any means, but...
>
> Here we might have a bit of a problem.  The notesfilter really
> does have to
> know if a message has ever been classified, not just whether or
> not it has
> been classified as spam.

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 :)

I think you should step back a little, and think about what the abstract
interface needs to do.  I see very few methods.  I can see that "id
changing" is an issue that also could be dealt with by the base class, so
that may complicate it a little.  But almost everything else seems to be
candidates for a "pop3proxy" sub-class.  There may even be scope for a
"header-enabled" sub-class, able to be used by all applications which can
implement everything from standard message headers, and thus able to be
shared by pop3proxy and notes.  Clear semantics for "copying" may be OK too,
as long as exactly what it means is explained (but I don't see the need)

A decent rule of thumb will be that whenever your abstract interface has the
concept using headers for *anything*, it wont make sense for Outlook, and
thus would be better placed in a sub-class.  Any assumptions about IDs,
other than that they are strings and that they may change over the life a
single object similarly.

When I find some more cycles for spambayes I will have a play with whatever
is in CVS at the time.

Mark.