wasm-demo/demo/ermis-f/imap-protocol/cur/1600095070.22772.mbox:2,S

32 lines
1.5 KiB
Plaintext

MBOX-Line: From brong at fastmail.fm Wed May 18 14:07:16 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: <alpine.OSX.2.00.1105181108180.24932@hsinghsing.panda.com>
References: <20110518011645.Horde.6sTkboF5lbhN03Jd3XNndCA@bigworm.curecanti.org>
<BANLkTikVbKdXg01nnajJ-=XLNfTpjjjG0Q@mail.gmail.com>
<alpine.OSX.2.00.1105181108180.24932@hsinghsing.panda.com>
Message-ID: <20110518210716.GA12636@brong.net>
On Wed, May 18, 2011 at 11:44:54AM -0700, Mark Crispin wrote:
> On Wed, 18 May 2011, Brandon Long wrote:
> >And this was our eventual solution. We don't expect clients to
> >implement our extensions for this, but since IMAP has become the
> >defacto Gmail API, it became necessary to expose some Gmail specific
> >data over IMAP for non-traditional applications.
>
> Too bad that the Gmail server is an incompatible and non-compliant fork
> that is (at best) barely usable with a standard IMAP client. This has
> obliged most uses of standard IMAP clients to give up on using the Gmail
> IMAP server in favor of POP or POP-over-IMAP download/delete.
What annoys me the most is no CONDSTORE/QRESYNC support, so you
can't create an efficient gmail client - you need to sync all the
flags, every time. Gmail is big enough that I'm fairly willing to
special case it in exchange for big performance wins, but there's
just no way to be sure you have all the changes.
Bron.