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

List:       kmail-devel
Subject:    Re: proposal for threading improvements
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-02-23 17:18:49
[Download RAW message or body]

On Sunday 23 February 2003 14:32, Till Adam wrote:
> This leads to the following problem:
>
> alice
>  |_till                     <- this mail is in Outbox
>      |_alice                <- In-Reply-To points to my message
>
> When trying to thread the last message, kmail looks at the
> In-Reply-To header, doesnt find the message that it is pointing to,
> since that is in my Outbox, and puts the message at toplevel.  What I
> would want to happen would be:
>
>      alice
>       |_alice
>
> Kmail needs to look at the References header and iterate from the
> back of the list over all references messages until it finds one in
> the current folder. I would guess, that in most cases the second to
> last message will be in the same folder, thus providing a very
> sensible place to thread the current message beneath.
>
> Ok, having formed this theory, I went about implementing a patch to
> prove it. I have local mboxes working as described above, but before
> sending the patch, I'd like to discuss this with you folks, since it
> turns out to be somewhat invasive. I did the following:
>
> - in kmfoldermbox.cpp, don't truncate the References header string
>   to the last one in the list, but keep the whole thing
> - in kmheaders.cpp, check not only In-Reply-To but iterate over
>   References from the back until a message in the current folder
>   is found (both in readSortOrder and writeSortOrder)
> - add References to KMMessage, KMMsgBase and
>   KMMsgInfoPrivate
> - add References string to the index (and bump the index
>   version up)

Instead of storing the In-reply-to string we only store an MD5 hash of 
this in the index (and we thread messages according to this hash 
value). You should do the same for the References. As you propose below 
it should be enough to store only the last two entries in the 
References header. Therefore I propose to only add the last but one 
References entry (as MD5 hash) to the index. (The last entry resp. the 
In-reply-to header, which both should be identical, is already there.)

> Now, because the References string can be longish, I had to increase
> the size limit in the STORE_DATA_LEN define, and of course having
> References in there makes the index bigger. It might be sufficient to
> keep only the last two mail ids in the References header to fix most
> cases and not have to increase the index size so much. Would that be
> preferrable?

Yes. See above.

> As for imap, from a cursory look over the relevant rfc, the ENVELOPE
> doesnt contain the References header, so there would be some
> additional work needed to get that and do the same magic for imap
> folders. I havent tackled that yet, as I wanted to run this by you
> folks first.
>
> Is all of this utter madness and someone has been selling me bad
> crack, or would you consider taking such a patch?

Your patch would be welcome.

> How about imap,
> what would you consider a half way clean approach to this?

IIRC (it was mentioned a while ago by someone) one can fetch single 
headers from the IMAP server. So the clean approach would be to fetch 
the ENVELOPE and the References header from the IMAP server. Carsten 
(or someone else who knows more about IMAP than me) can probably give 
you a better answer.

Regards,
Ingo


[Attachment #3 (application/pgp-signature)]
_______________________________________________
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]