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

List:       kmail-devel
Subject:    Re: proposal for threading improvements
From:       Don Sanders <sanders () kde ! org>
Date:       2003-02-24 3:25:20
[Download RAW message or body]

On Monday 24 February 2003 03:18, Ingo Klöcker wrote:
> 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)

Sounds very well thought out.

> 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.)

I like this idea. So I guess it makes sense to add something like a 
REPLYTOAUX_SET=0x4000 to the enum in KMMsgInfoPrivate, and a QString 
replyToAuxIdMD5.

(BTW I know modifiers is a ushort but we should be able to bump that 
up to a uint as we run out of space in the enum).

> > 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.

Yeah, please consider using a new enum in kmmsginfoprivate and adding 
new replyToAuxIdMD5 and setReplyToAuxIdMD5 methods to KMMsgInfo.

> > 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.

Very welcome here also.

> > 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.

BTW I might be working on adding support for subject based threading 
soon.

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]