[Email-SIG] API for email threading library?
Stephen J. Turnbull
stephen at xemacs.org
Sat Jan 7 05:17:01 CET 2012
Bill Janssen writes:
> 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 don't know if it belongs there, although that's the obvious place.
There are a other threaded message structures that aren't email (or
netnews, which is obviously basically the same thing). For example,
issue trackers.
> * Should M be required to be "email.message.Message",
-1
> or perhaps some less restrictive type, say
> "ThreadableMessageAPI"? All that's strictly required is the
> ability to retrieve the Message-ID, Subject, Date, References,
> and In-Reply-To fields.
If a variety of existing apps are to be able to plug this in, the API
shouldn't be bound to email.message.Message. +1 for duck-typing.
> * What operations should be possible on C? Some that come to mind:
>
> * retrieve_thread (M or message-id) => T
> * add_message (M) => T
> * add_messages (set of M) => None
> * remove_message (M or message-id) => T (or None) ?
* Reparent message (this will actually merge threads).
> * What's the interface for T? It's a tree with possible dummy nodes, so
> a tuple of messages plus nested tuples would do it. What should the
> nodes in the tree be? Normalized (see RFC 5256) Message-IDs?
In a Lisp implementation of http://www.jwz.org/doc/threading.html I'm
working on, I just use symbols named by the message IDs themselves;
I'm not familiar with the normalization yet.
> email.message.Message instances?
I think it should be more abstract than that.
More information about the Email-SIG
mailing list