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

31 lines
2.3 KiB
Plaintext

MBOX-Line: From jkt at flaska.net Mon Jan 28 16:07:59 2013
To: imap-protocol@u.washington.edu
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
Date: Fri Jun 8 12:34:50 2018
Subject: [Imap-protocol] Re: Courier =?iso-8859-1?Q?bug(=3F)?=
In-Reply-To: <20130128145843.Horde._nr6MiWpMYirI_cZr53iQQ8@bigworm.curecanti.org>
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>
Message-ID: <e11b637d-71b6-4482-8a10-0980320bd20c@flaska.net>
On Monday, 28 January 2013 22:58:43 CEST, Michael M Slusarz wrote:
> rather than trying to keep a sequence->UID map (ugh)
If you maintain any sort of persistent cache, you want to remove obsolete items from there. Prior to QRESYNC, the only way a server could tell you about expunges was via, well, the EXPUNGE response which uses sequence numbers. This means that you either don't have message data cached locally, or you absolutely have to have uid->seq mapping for the full range of messages which you have in your cache. If you don't have that, you don't know whether the expunge the server has just told you refers to something you have or whether it can be ignored.
You can certainly make optimizations like speculating that expunges will likely happen at the end of the UID range. The question is whether it is worth the effort in presence of ESEARCH and QRESYNC. There are other reasons which speak heavily in favor of maintaining the full mapping at all times; for example in Trojita, supporting the THREAD command without that would be rather complex (you want to work with UIDs to cache that infromation across reconnects etc etc etc).
And just for completeness, what I spoke about was *maintenance* of the full seq->UID mapping, not fetching it all the time. There are ways of updating the mapping since the last time with only minimal traffic in most common situations -- and as I tried to show in the other thread, UIDNEXT is vital for them.
With kind regards,
Jan
--
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/