- Previous message: Bron Gondwana: "Re: [POLL] Development guidance"
- Maybe in reply to: Ken Murchison: "[POLL] Development guidance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Ken Murchison (no email)
Date: Mon Nov 05 2007 - 19:10:08 EST
Bron Gondwana wrote:
> On Mon, Nov 05, 2007 at 04:58:59PM +0000, David Carter wrote:
>> On Fri, 2 Nov 2007, Ken Murchison wrote:
>>
>>> I'm getting ready to implement the QRESYNC extension for the upcoming
>>> LEMONADE interop.
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-06.txt
>> Reading the Internet Draft, I'm a little puzzled by:
>>
>> 4.3. Additional state required on the server
>>
>> [...]
>>
>> Also note that if the UIDVALIDITY of the mailbox changes [...], then
>> any state associated with expunged messages MUST be deleted as well.
>>
>> I'm not clear what the motivation is here given that a new UIDvalidity
>> forces a full resync from any client: no QRESYNC is possible.
>>
>> This requirement is likely to be a pain for:
>>
>>> 1. Leverage delayed expunge which already stores state for expunged
>>> messages in cyrus.expunge (up until the records are purged by cyr_expire).
>> Given that unexpunge assigns a new UIDvalidity to the mailbox.
>
> I think that unexpunge should actually be the same as "COPY" where the
> source is the "deleted" record. This updating UIDvalidity is just rude,
> especially if you're only unexpunging a couple of messages from a much
> bigger mailbox.
>
> SEEN state handling is a pain, but that's always been a pain. I don't
> mind too much if an unexpunged message shows up as "unseen" in its
> new incarnation.
I think I agree. We have to change the UID of the unexpunged message to
UIDNEXT, and rename() the message file accordingly.
-- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University
|
|
|