73 lines
3.4 KiB
Plaintext
73 lines
3.4 KiB
Plaintext
MBOX-Line: From slusarz at curecanti.org Wed Jan 30 10:12:51 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Michael M Slusarz <slusarz@curecanti.org>
|
|
Date: Fri Jun 8 12:34:50 2018
|
|
Subject: [Imap-protocol] Re: Courier bug(?)
|
|
In-Reply-To: <CAKHUCzxKfjSseoMKQ6bm0-TCPs2RVemLZSdTaLv5JueOeR8_6w@mail.gmail.com>
|
|
References: <20130121144822.Horde.kbr5Y8IKwMlD1fH1Qun9hQ1@bigworm.curecanti.org>
|
|
<CAKHUCzwJ8xq7O8vGDHe0D9Jviac06o-QtePMhKYV7HzwzRPMPA@mail.gmail.com>
|
|
<1358846428.12608.2.camel@hurina>
|
|
<CAC4RtVAobTOjLdLH++_qp=HCtdZJne5Q7TUF_P=9J6a+gg2fmQ@mail.gmail.com>
|
|
<51015F8D.8020300@isode.com>
|
|
<9ade1aaa-6d67-443b-8fa3-43f00486d4cb@flaska.net>
|
|
<20130128145843.Horde._nr6MiWpMYirI_cZr53iQQ8@bigworm.curecanti.org>
|
|
<CAKHUCzxKfjSseoMKQ6bm0-TCPs2RVemLZSdTaLv5JueOeR8_6w@mail.gmail.com>
|
|
Message-ID: <20130130111251.Horde.qK1Vnj9NDTc5P1ZhVgIUAA9@bigworm.curecanti.org>
|
|
|
|
Quoting Dave Cridland <dave@cridland.net>:
|
|
|
|
> On 28 Jan 2013 22:00, "Michael M Slusarz" <slusarz@curecanti.org> wrote:
|
|
>> IMHO, a more sensible approach for a disconnected client, rather than
|
|
> trying to keep a sequence->UID map (ugh)
|
|
>
|
|
> No, really, this is a sensible thing to be doing for a number of reasons.
|
|
>
|
|
> Firstly, it'll help if you don't get a UID, and secondly there's all sorts
|
|
> of interesting tricks you can do if you know the UID/seq mapping.
|
|
|
|
I'm sure that some clients see some benefit from these tricks, but
|
|
that certainly doesn't mean that all clients will.
|
|
|
|
> Not least QRESYNC more or less requires you to, if you want it to be
|
|
> efficient in telling you what's been expunged.
|
|
|
|
In practical usage, this is not true. We actually wrote all the code
|
|
to handle seq/UID mappings and use this information to populate the
|
|
4th argument to QRESYNC. And we discovered it was all a giant waste
|
|
of time. The effort in maintaining the mapping and producing the 4th
|
|
argument every time a mailbox was opened *far* outweighed any benefit
|
|
from obtaining more compact VANISHED responses. Mainly because any
|
|
user only has at most several hundred cached entries in any given
|
|
mailbox (even if that mailbox contains hundreds of thousands of
|
|
messages). So that code was ripped out almost immediately.
|
|
|
|
With connected clients it might make sense since they have a full (or
|
|
mostly full) copy of the mailbox in the local cache. But with a
|
|
disconnected client and/or a client that implements a view/window
|
|
based interface to a mailbox, the number of cached entries will be
|
|
much closer to the size of the window rather than the size of the
|
|
mailbox (,as the mailbox size increases). YMMV.
|
|
|
|
>> Only if these 3 items occur does a client need some other way of linking
|
|
> the flag changes with an UID. Since this event should occur only extremely
|
|
> rarely, if at all, one appropriate way of correctly syncing the local cache
|
|
> would be to:
|
|
>>
|
|
>> 1. Ignore the returned FETCH information for local caching purposes.
|
|
>> 2. Immediately reopen the mailbox. (The client's existing
|
|
> CONDSTORE/QRESYNC will ensure that the mailbox is correctly sync'd).
|
|
>
|
|
> Yikes.
|
|
>
|
|
> Well, that'll work, of course, but it's pretty inefficient.
|
|
|
|
The inefficiency of this code is irrelevant since it is *NEVER* run.
|
|
I've yet to see a real-world example of an existing CONDSTORE/QRESYNC
|
|
server that even triggers this code. So the code is there to ensure
|
|
the spec is followed, but the optimization is to real-world usage, not
|
|
the black letter of the RFC.
|
|
|
|
michael
|
|
|
|
|