MBOX-Line: From tss at iki.fi  Thu Jan 31 12:41:03 2008
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:41 2018
Subject: [Imap-protocol] INTHREAD extension
In-Reply-To: <TldMZqVh3ZR4WuYtIhsXug.md5@libertango.oryx.com>
References: <1201808382.8854.206.camel@hurina>
	<TldMZqVh3ZR4WuYtIhsXug.md5@libertango.oryx.com>
Message-ID: <0728004D-B194-4C4B-A4BA-F6E0E6048082@iki.fi>

On Jan 31, 2008, at 10:25 PM, Arnt Gulbrandsen wrote:

>> I'd like to make it slightly simpler though. I think it would be  
>> enough if it worked only with THREAD command, and only using the  
>> same thread algorithm as selected for THREAD.
>
> Elaborate, please?

The main use I see for INTHREAD is to let client display a list of  
threads where a search condition matches. This would be done with  
THREAD algorithm .. INTHREAD same-algorithm .. command. And since they  
use the same algorithms, it's most likely possible to optimize for  
that (I haven't thought of how yet). But if the INTHREAD needs to work  
with different algorithm than THREAD or if SEARCH INTHREAD is allowed,  
it can't use the THREAD's optimized code path, requiring an  
alternative nonoptimized code path which will be rarely (if ever) used.

Do you see any real use for SEARCH INTHREAD or THREAD algo1 INTHREAD  
algo2 commands?

-------------- 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://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080131/38ffc04e/attachment.sig>
