[Imap-protocol] Optimistic incremental THREAD=REFERENCES
tss at iki.fi
Fri May 9 14:52:30 PDT 2008
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
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
More information about the Imap-protocol