We've enabled CONDSTORE on an entire Store here at FastMail
to get an idea of what's involved in supporting it. (it's the
store that the FastMail staff are on, so we're testing it on
ourselves first!)
So - there's a problem where \Seen changes are not causing the
modseq information
Hi Ken, everyone,
Can anyone think of a good reason why CONDSTORE isn't enabled
by default for everyone all the time? Back when it wasn't
stable, fair enough - but I think it's pretty close now, and
am willing to put a bit more effort in to finishing the job...
Thunderbird 3 will support
from other flags), I didn't want to force CONDSTORE on people
until we had a good handle on the performance hit.
Bron Gondwana wrote:
Hi Ken, everyone,
Can anyone think of a good reason why CONDSTORE isn't enabled
by default for everyone all the time? Back when it wasn't
stable, fair enough
},
+{ /vendor/cmu/cyrus-imapd/sharedseen,
+ OPT_IMAP_SHAREDSEEN },
+{ /vendor/cmu/cyrus-imapd/condstore,
+ OPT_IMAP_CONDSTORE },
+{ NULL, 0 }
+};
+
/* To free values in the mailbox_annotation_rock as needed */
static void cleanup_mbrock(struct mailbox_annotation_rock *mbrock
On Mon, 12 Nov 2007, Rudy Gevaert wrote:
Cyrus has support for condstore. However when using replication condstore
doesn't work.
Could someone explain to me what the downside is when have condstore enabled
on a mailbox and using replication?
You will lose almost all modseq updates, which
Hello,
Cyrus has support for condstore. However when using replication
condstore doesn't work.
Could someone explain to me what the downside is when have condstore
enabled on a mailbox and using replication?
Thanks in advance
