[spambayes-dev] Message classes

[Meyer, Tony]

> I think email.Message could be an internal implementation 
> detail of message.Message.  I think we need a clear API for 
> message.Message, including all transformations to and from 
> "external" representations, and clear semantics for the 
> object once "transformed" from the Outside world.  I believe 
> it is in these transformations that the oft mentioned "choke 
> point" for handling badly formed mail must live.  Also, as I 
> mentioned, I am semi-keen to try falling back to rfc822 when 
> email.Message chokes, just for the ascii.

+1.

For the moment, I'm going to remove Corpus.Message, and change
FileCorpus.FileMessage to inherit from message.Message instead.  As far
as I can see Corpus.Message and message.Message are trying to do much of
the same thing, anyway.

I'll leave msgs.Msg alone since it's only for testing.  I think that
mboxutils is much the same as the Outlook plugin, in that it one day
will use message.Message, but it's too much hassle for the moment.  Once
message.Message has the 'choke point' code, the gain should be worth the
pain.

I've done a quick change and pop3proxy seems to still work, but I'll
wait to check things in until after the alpha3 release I want to do on
Friday.  This will give others (hopefully including TimS) a chance to
correct my misunderstandings...

If I feel inspired I might start work on writing up a clear
message.Message API, but otherwise not :)

=Tony Meyer