Re: [POLL] Development guidance

From: Bron Gondwana (no email)
Date: Mon Nov 05 2007 - 18:11:46 EST

  • Next message: Ken Murchison: "Re: [POLL] Development guidance"

    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.

    Bron.


  • Next message: Ken Murchison: "Re: [POLL] Development guidance"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD