[Imap-protocol] Optimistic incremental THREAD=REFERENCES

[Timo Sirainen]

On May 10, 2008, at 12:06 AM, Arnt Gulbrandsen wrote:


> I wrote code do to the same thing, and found another corner case. If  

> one or more early message(s) is/are deleted from the mailbox, then  

> it can be (and very seldom is) the case that a thread is split.

>

> Consider this four-message thread:

>    1 is the start.

>    2 has an In-Reply-To pointing to 1.

>    3 has an In-Reply-To pointing to 1

>    4 has an IRT pointing to 2

>

> If you thread this incrementally, you learn that this is one thread.

>

> If messages 1 and 2 are deleted and another message arrives

>    5 has an IRT pointing to 3

> then your incremental algorithm may still have enough information to  

> tie messages 3, 4 and 5 together in one thread. A non-incremental  

> T=R doesn't have that information, and will make two threads.


A quick test shows that my algorithm handles this, probably because of  
the refcounting rules. I'll look at it more closely later to make sure  
that it does.


> The subject-joining rule magnifies this. Personally I didn't  

> imnplement the subject-joining bit.


Me neither. That generates more complexity and I'd rather drop the  
subject merging completely (my X-REFERENCES2 threading algorithm does  
that).

BTW. This reminds me of your INTHREAD draft with THREAD=REFS. I guess  
by "THREAD=REFS ignores Date" you mean that you don't care in which  
order the threads are returned? Or are they returned sorted by  
INTERNALDATE? Or sequences? Anyway I don't think you should drop the  
In-Reply-To header handling. That makes it difficult to use the same  
persistent thread information for both THREAD=REFERENCES and  
THREAD=REFS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 201 bytes
Desc: This is a digitally signed message part
Url : http://mailman1.u.washington.edu/pipermail/imap-protocol/attachments/20080509/edf53d38/PGP.bin