38 lines
1.6 KiB
Plaintext
38 lines
1.6 KiB
Plaintext
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>
|