[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [Bug 54474] changing subject does not break thread
From:       Don Sanders <sanders () kde ! org>
Date:       2003-02-18 5:21:36
[Download RAW message or body]

On Sunday 16 February 2003 22:47, Ingo Klöcker wrote:
<snip>
> Actually I thought we were talking about the generation of
> In-reply-to and References headers for composed replies and not
> about threading received messages. It seems I misunderstood the
> original wish.

Or perhaps I misunderstood it. Regardless the questions to be 
considered for the receiving and sending cases are the same. But I 
would like to concentrate on the receiving case for now.

So starting over. I would like to implement subject based threading. I 
see this task as consisting of two subtasks.

1) Breaking threads when messages have been incorrectly threaded due 
to 'abuse' of the reply button.
2) Adding to a thread when the mua used to create a message has failed 
to set the reply-id header field correctly.

For the moment I would like to just consider (1).

So considering (1) I find it annoying in threading mode when a lazy 
person abuses the reply button and sends a message with the reply-id 
field set instead of being empty. I think pretty much everyone finds 
this annoying, and would like it to be fixed.

I would like to fix this annoying reply-id incorrectly set problem, by 
looking at the subject of the mail. A side effect of this technique 
is that it will cause certain threads to be broken that were 
previously kept together. David Bishop gave an example of such a 
message.

Personally I think breaking threading in the Bishop case is not wrong. 
I'm not saying it's clearly right, I think it's a grey area, there is 
no clear wrong or right. Contrast this with the abuse of the reply 
button, I think any reasonable person would consider threading the 
message in this case to be wrong.

Personally, my personal feeling, is that I would like to fix the 
problem with the abuse of the reply button messages being threaded 
and I am 100% ok with messages without subject prefixes being 
inserted at the top level instead of being inserted as children in a 
thread.

In my opinion this would fix what is definitely a bug, and also have 
side effects in a grey area where there is no clear wrong or right.

To do this I would like to make a change like the following in 
KMMsgInfo::init
      kd->replyToIdMD5 = KMMessagePart::encodeBase64( replyToId );
+      if (kd->subject  == KMMessage::stripOffPrefixes(kd->subject))
+         kd->replyToIdMD5 = QString::null;

(and a similar change to KMMessage::replyToIdMD5)
  
That is if the subject contains no reply prefixes then clear the 
replyToIdMD5 field. (This field is only used for message threading in 
kmheaders).

Now as I've shown I'm prepared to compromised and implement a more 
complicated solution that only clears the replyToIdMD5 if the message 
does not contain any quoted text. Personally I don't think that 
complexity is beneficial but I'm trying to negotiate a reasonable 
solution to the problem.

The problem being that messages resulting from abuse of the reply 
button are incorrectly threaded. I think this is definitely a 
problem, it's annoying and I would like to fix it.

This problem can't be fixed at sending time, because problematic 
messages are created in mail clients other than KMail.

The problem can be fixed at receiving time, albeit with a side effect 
on messages where people have manually changed the subject. Now 
overall I expect the benefits of breaking incorrectly congealed 
threads to outweigh any negatives. That is overall I expect the 
change proposed above to be beneficial.

I would like to try out the proposed change, or some reasonable 
variant of the proposed change. Perhaps instead of making this change 
in isolation it also makes sense to make a change to solve problem 
(2) in conjunction with solving this problem. Solving (1) breaks 
threads up, solving (2) brings messages together into a thread, so 
there is a kind of counter-balance here.

However what I don't think is right is to simply rule out the change I 
proposed above without even trying it.

Don.

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]