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. _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
