MBOX-Line: From tss at iki.fi  Fri Mar 31 14:14:42 2006
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] Thread extension
In-Reply-To: <Pine.OSX.4.64.0603310950110.26204@pangtzu.panda.com>
References: <1143819932.8744.163.camel@localhost.localdomain>
	<Pine.OSX.4.64.0603310950110.26204@pangtzu.panda.com>
Message-ID: <1143843283.3985.18.camel@hurina>

On Fri, 2006-03-31 at 10:08 -0800, Mark Crispin wrote:
> 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.

I like being able to see all the new mail at once without having to jump
around.

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

Well, that's fine with me too.

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

Aren't most new messages simple insertions? Either a reply to an
existing message, or a new message with no message-id references. Those
cases could be optimized and the other cases could then fallback to
slower way.

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

If most changes are simple insertions, then I think it should be pretty
easy for those cases. And in case something else happens to the threads,
it would return everything again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20060401/bd20f284/attachment.sig>
