47 lines
1.6 KiB
Plaintext
47 lines
1.6 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Thu Jan 31 12:51:39 2008
|
|
To: imap-protocol@u.washington.edu
|
|
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
Date: Fri Jun 8 12:34:41 2018
|
|
Subject: [Imap-protocol] INTHREAD extension
|
|
In-Reply-To: <0728004D-B194-4C4B-A4BA-F6E0E6048082@iki.fi>
|
|
References: <1201808382.8854.206.camel@hurina>
|
|
<TldMZqVh3ZR4WuYtIhsXug.md5@libertango.oryx.com>
|
|
<0728004D-B194-4C4B-A4BA-F6E0E6048082@iki.fi>
|
|
Message-ID: <wa2x5K++tj1nUX9M74JMrQ.md5@libertango.oryx.com>
|
|
|
|
Timo Sirainen writes:
|
|
> The main use I see for INTHREAD is to let client display a list of
|
|
> threads where a search condition matches.
|
|
|
|
I see. (That's my second purpose, too.)
|
|
|
|
> This would be done with THREAD algorithm .. INTHREAD same-algorithm ..
|
|
> command.
|
|
|
|
I thought of SEARCH INTHREAD for that. That gives a more natural
|
|
fallback to servers without INTHREAD.
|
|
|
|
> And since they use the same algorithms, it's most likely possible to
|
|
> optimize for that (I haven't thought of how yet).
|
|
|
|
Maybe. Not for me: My code will be a bit faster and use less disk space
|
|
if everyone uses the same algorithm, but if two algorithms are used, it
|
|
doesn't matter whether they're used by the same or by two different
|
|
clients.
|
|
|
|
> 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
|
|
|
|
Yes. But I also want INTHREAD in the search key used to control mailbox views.
|
|
|
|
> or THREAD algo1 INTHREAD algo2 commands?
|
|
|
|
No that. Not at all.
|
|
|
|
Arnt
|
|
|