[Email-SIG] API for email threading library?

[Stephen J. Turnbull]

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.