Logged In: YES 
user_id=6405

Date: 10 Dec 2001 18:04:15 +0100
From: Patrick Ohly

The biggest change is the support for message threading 
with In-Reply-To in the message headers. There are three 
situations here: a reply by email to an existing issue 
where we have a In-Reply-To which is dropped by roundup 
when storing this reply in its database and then bouncing 
it to the nosy list; an issue is modified by web; creating 
a new issue via email and bouncing it back to the author.

What I did is adding a "inreplyto" property to my issue 
and msg classes. If the mail gateway adds a msg node, it 
sets its inreplyto to the same value that the incoming 
email had, and the roundupdb code adds it again when it 
sends this msg. This solves the first case and allows deep 
nesting just as in normal email discussions. Using the 
message id if it is a new issue solves the last case.

The roundupdb also treats the very first msg for an issue 
in a special way: it creates the Message-Id itself (from 
the roundup email address and the designator), and stores 
this id in the inreplyto property of the issue. This id is 
used for all msgs which don't have their own inreplyto, 
e.g. for those created via web. That way one can have at 
least a "flat" thread which is anchored in the first msg 
for this issue.

There are a few issues with these patches: roundupdb 
should still work if the inreplyto property is not present 
in the database scheme, but catching KeyError is perhaps 
not the best solution to do that. I know that mailgw 
breaks when trying to set the inreplyto property if it 
isn't there - I don't really know how to do it better in 
the self.db.msg.create() call. I also don't know how to 
store None as property value - should the property be 
omitted? mailgw currently stores empty strings instead, 
which isn't quite the same.