47 lines
2.1 KiB
Plaintext
47 lines
2.1 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Wed May 18 15:03:32 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:46 2018
|
|
Subject: [Imap-protocol] Thoughts on keyword improvements/enhancements
|
|
In-Reply-To: <BANLkTik8Zz_n8Ub0i1tDkO8q62w8fnJK8w@mail.gmail.com>
|
|
References: <20110518011645.Horde.6sTkboF5lbhN03Jd3XNndCA@bigworm.curecanti.org>
|
|
<BANLkTikVbKdXg01nnajJ-=XLNfTpjjjG0Q@mail.gmail.com>
|
|
<alpine.OSX.2.00.1105181108180.24932@hsinghsing.panda.com>
|
|
<20110518210716.GA12636@brong.net>
|
|
<BANLkTik8Zz_n8Ub0i1tDkO8q62w8fnJK8w@mail.gmail.com>
|
|
Message-ID: <20110518220332.GA17078@brong.net>
|
|
|
|
On Wed, May 18, 2011 at 02:47:38PM -0700, Brandon Long wrote:
|
|
> Its on our roadmap, though it requires some fairly extensive changes
|
|
> to our backend store. May not happen until next year.
|
|
|
|
Fair enough. I'm actually more interested in some of the other
|
|
stuff. I should look at how you did the threading and the unique
|
|
message ids and see if there's any way we can make it interoperate
|
|
at all with how Cyrus does GUID (sha1 of message body) and the
|
|
conversations stuff we're doing at Opera/FastMail - which is also
|
|
super non-standard.
|
|
|
|
> CONDSTORE was published when we started, but QRESYNC wasn't.
|
|
> CONDSTORE would have been a lot of problems on our existing backend,
|
|
> and it didn't appear any clients implemented it. That's one issue
|
|
> we've had on whether to expend the effort on any particular extension
|
|
> is knowing whether or not any clients would actually take advantage of
|
|
> it.
|
|
|
|
Yeah - CONDSTORE was a pain when it came in to Cyrus too, but it turns
|
|
out to be very good at making a low bandwidth replication protocol as
|
|
well, because you can avoid the downside (no memory of deletes) by
|
|
caching the modseq at which you deleted a message. Which is exactly
|
|
what QRESYNC buys as well.
|
|
|
|
> We do try to be fast for the traditional UID FLAGS fetch, but its
|
|
> still O(messages) so it can get slow for large mailboxes, and the data
|
|
> transfer isn't anything to sneeze at either.
|
|
|
|
Yeah, the data transfer is the real problem. At least you support
|
|
COMPRESS!
|
|
|
|
Bron.
|
|
|