MBOX-Line: From mrc at CAC.Washington.EDU  Fri Mar 31 10:08:00 2006
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] Thread extension
In-Reply-To: <1143819932.8744.163.camel@localhost.localdomain>
References: <1143819932.8744.163.camel@localhost.localdomain>
Message-ID: <Pine.OSX.4.64.0603310950110.26204@pangtzu.panda.com>

On Fri, 31 Mar 2006, Timo Sirainen wrote:
> The "sort threads by their first message's date" behavior is bad because
> new messages can't be easily noticed in the mailbox.

My MUA has a way to take me to new messages regardless of how they are 
ordered in the mailbox.  That might be a useful feature for your MUA.

> So, there should be
> some way to specify "sort thread by their latest message's received
> date" (and date-header?).
> There has been talk about this before, but I guess no-one's done
> anything about this? How about a new extension, eg. THREADEXT which
> allows specifying the thread sorting in some way

The way to define a new threading algorithm is...to define a new threading 
algorithm!  There is no need for THREADEXT that adds suboptions to an 
algorithm when you just just define a new THREAD=xxx.

There is already a very nasty comment in Wikipedia about IMAP's complexity 
(at least it now longer says "20 orders of magnitude more complex than 
POP3").  I don't think that we should increase complexity by adding 
sub-options to sub-options, which is effectively what adding options to 
modify threading does.

Put another way: if a way of threading is valuable enough, there is plenty 
of room in the namespace to define a new algorithm.  If it isn't valuable 
enough to define a new algorithm, then that cost serves as a desirable 
barrier to keep bloat out of the protocol.

> Also another separate thing related to threads: Has anyone tried
> optimizing the THREAD command in a way that after the initial threading,
> the results would be stored somewhere and later when a new mail arrives,
> the new thread list could be generated without having to rebuild
> everything?

People have tried to work out how to do insertion in THREAD results.  It 
is not a simple task.  A single message can completely change the thread 
results.  It's not just one link tying together two threads; a message can 
have references that tie together an unbounded number of links.

In fact, THREAD was what shot down an insertion mechanism for SORT, when 
it was pointed out that most users will thread rather than sort.

> I haven't thought about this much yet, but I was hoping to find out a
> way where I could just store the final thread reply and insert the new
> mail in there with a single scan through all the messages in the mailbox
> (looking at their message-id, in-reply-to, references and subject
> headers but without actually having to store most of them to memory).

The cost is not memory in the server.  The cost is the network I/O cost of 
transmitting the new thread results.

If you have an insight on how to express alterations to a thread tree that 
does not entail greater complexity that is saved, lots of people would be 
delighted to hear it (myself included).

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

