77 lines
3.8 KiB
Plaintext
77 lines
3.8 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Mon Oct 31 15:38:49 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:46 2018
|
|
Subject: [Imap-protocol] BODY.PEEK[section]<origin.size> FETCH response
|
|
In-Reply-To: <75E51A44-91E4-48D1-BA82-789C82583ABC@iki.fi>
|
|
References: <8F0DA5FA-FB07-4AFA-9C58-8F0927998343@ghoti.org><alpine.OSX.2.00.1110301823210.9034@hsinghsing.panda.com><CABa8R6uyrHJ6AqQoGfMcLztG-zovaVK4FEFep8ibpYc2-6b7ig@mail.gmail.com><alpine.OSX.2.00.1110311352000.9034@hsinghsing.panda.com><CABa8R6ugaAADsrvaS1Nnau5bi7k9728b+x00NcG1Nbxfk9xwsA@mail.gmail.com>
|
|
<75E51A44-91E4-48D1-BA82-789C82583ABC@iki.fi>
|
|
Message-ID: <1320100729.24671.140660992928641@webmail.messagingengine.com>
|
|
|
|
|
|
|
|
On Tuesday, November 01, 2011 12:18 AM, "Timo Sirainen" <tss@iki.fi> wrote:
|
|
> On 31.10.2011, at 23.53, Brandon Long wrote:
|
|
>
|
|
> >> If you think that Gmail's IMAP server is compliant, you are mistaken.
|
|
> >
|
|
> > I know its not compliant, we even have a support page where we list
|
|
> > the cases where we explicitly decided against compliance.
|
|
> > Interoperability is a goal, however. That doesn't mean we want to
|
|
> > force Gmail users to use the IMAP mailbox model, however.
|
|
>
|
|
> I haven't tested GMail with imaptest for a while now (few years?), but I don't think the bugs it reports are about the mailbox model, or anything else that can't be fixed somewhat easily. I guess the one test I could remove is the search for substrings, since even Mark doesn't think it's worth the trouble nowadays.
|
|
|
|
I've nearly got 'fetchnext' working on all the database engines I care about,
|
|
so I can efficiently implement a proper handling of the LIST-EXT edge cases.
|
|
|
|
------------
|
|
|
|
Not that anyone much cares about those. Most clients just want LIST "" * to work
|
|
fast rather than building up a tree with a zillion round trips - and for it to
|
|
return the XLIST/SPECIAL-USE and subscription status along with the result,
|
|
they would be ecstatic. If you could rely on that, then most clients would
|
|
just call the one call and be happy.
|
|
|
|
Oh, and I'm sure for bandwidth usage reasons, those same clients would also
|
|
love it to return a MODSEQ, which they could offer along with a IFCHANGEDSINCE
|
|
which returned the moral equivalent of a 304.
|
|
|
|
Or even better, a response to login which included a separate MODSEQ value
|
|
for those rarely changed things, so every client login included a "your
|
|
cached values for the following things are already fine, you don't need to
|
|
ask again".
|
|
|
|
Man, wouldn't that be nice.
|
|
|
|
For that matter, you could go the step further we're heading to with our
|
|
in-house Cyrus builds now, where there's a global HIGHESTMODSEQ and a global
|
|
UIDVALIDITY for all one user's folders. Along with UIDVALIDITY change on
|
|
rename, you only need to read that ONE value to be sure that no folders
|
|
have been changed.
|
|
|
|
(yes, we do bump it on DELETE as well, a nice side affect of DELETE just
|
|
being a rename into a hidden namespace, where it lounges for a week before
|
|
being properly cleaned up)
|
|
|
|
And you can just check the one HIGHESTMODSEQ value, to be sure that nothing
|
|
has changed in ANY folder. That's a great first-level check. After that
|
|
you need to also check the modseqs on any folders to drill down to where the
|
|
change may have occurred - but they're in the statuscache, so you can fetch
|
|
that information for the cost of a single linear read. Only the actually
|
|
changed folder need be opened.
|
|
|
|
Along with event push to clients (out of band) just saying "something's
|
|
changed, do a poll" we can get fast, efficient updates for all folders.
|
|
The intermediate layer is JSON, but hey - that keeps the browser client
|
|
happy, and everything else can talk it too. Someone did a benchmark of
|
|
a pile of Perl serialisation options, and the JSON::XS won - even over
|
|
the native Storable, so it's no slouch either.
|
|
|
|
Bron.
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|
|
|