[Email-SIG] API for email threading library?

R. David Murray rdmurray at bitdance.com
Fri Jan 6 02:30:22 CET 2012


On Thu, 05 Jan 2012 20:21:08 -0500, Barry Warsaw <barry at python.org> wrote:
> On Jan 05, 2012, at 09:55 AM, Bill Janssen wrote:
> 
> >Folks, I'm working on an implementation of RFC 5256 email threading,
> >designed so that it could fit as a submodule in the "email" package, if
> >such a think was ever seen to be useful.
> 
> I really like the idea of threading support being included in the email
> package.  (I admit that I don't have time right now to read the RFC.)  My
> general thoughts are that the actual messages needn't be included in the
> thread collection, but perhaps just Message-IDs.  That would allow an
> application to store the actual message objects anywhere they want, and would
> reduce space requirements of the thread collection.

I don't have time to read the RFC either :(.  But from a skim of the
first bits, my immediate reaction is that the best thing to do is to break
everything down into as many discrete components as practical (pluggable
thread storage, thread construction (which presumably takes duck typed
Message objects containing at least the relevant headers) with different
subclasses or plugins for the different sorting algorithms, thread query,
etc) and keep them as decoupled as possible.  That would give a server
implementer the greatest flexibility.  You'll probably want to noodle
on the various APIs and make some concrete (but not fully fleshed out)
proposals for discussion.  That's the procedure that seemed to work best
when we were working on the email6 API.

On a possibly related note, it has become clear to me through work I've
done recently that the parser/generator classes need some non-trivial
refactoring to make using external (not in-the-object-in-memory) storage
of all or parts of the message possible.  I'm not at all sure when I'll
have time to work on that, but I've got a bunch of relevant notes for
use when I do :)

--David

PS: If you implement the 'base subject' algorithm I bet we can get
agreement to check that right in to email.utils before 3.3 :)


More information about the Email-SIG mailing list