Thanks for all the feedback, folks.
After musing about all of this, it seems to me that threading makes no
sense outside the context of a message store (or forum post store, or
netnews article store, or...). So I'm going to push all the decisions
about "what's a message anyway" into an abstraction of such a message
store:
class ThreadableObjectStore:
@abstractmethod
get_message_id(msg) => message-ID (string)
@abstractmethod
get_subject(msg) => subject (string)
@abstractmethod
get_date(msg) => timestamp (float, seconds past epoch)
@abstractmethod
get_references(msg) => sequence of message-ID (list of string)
So your particular instantiation of ThreadableObjectStore can decide
what a 'msg' is, what a message-ID is, whether they're normalized, etc.
An instance of a ThreadableObjectStore will be required to create an
instance of a threadset. I'll provide such a class for mailbox.Mailbox,
for testing.
Also, I think that persistence of the threading analysis is really a
function of the message store, not the threadset. So what the threadset
requires is simply
(1) a way to externalize its threads in a meaningful way, which a
forest of tuple trees with message IDs at the nodes works perfectly
well for, and
(2) a way to take such a representation and revivify it, given a
message store.
Bill
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
