[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MODSEQ in CONDSTORE
On Wed, 1 Feb 2006, Dave Cridland wrote:
Two stores on different messages generate two different MODSEQ values,
though. So if it were 32-bit, then just filling a mailbox would be enough to
exhaust it. You actually only need 2^32-1 STORES on a single message - the
arrival of the single message itself increments the MODSEQ.
Yes, but how likely is a mailbox to have anything near the order of
magnitude of 2^32-1 messages (which would exhaust the UID space)? Even
given a ridiculous number of messages in the mailbox, there should be tens
of thousands of updates possible for each message before a 32-bit MODSEQ
space runs out.
The examples imply MODSEQ as a date/time, but as the document says you
can't actually do that.
Indeed, but it's possible to come close. ACAP uses modtimes that can't
actually be times, they just look remarkably like them.
I don't consider that to be a feature. Some client author will depend
upon that characteristic, and it will come back to bite you.
I don't think there's anything which states explicitly that if a STORE
results in no change then no MODSEQ increases happen, but I'd assume that was
implicit in the definition.
Well, that's a bug in the definition.
FWIW, Ken Murchison's patch for Cyrus can use a 32-bit MODSEQ value. There's
nothing *forcing* the value to be 64-bit for servers, but if you overflowed a
32-bit, you'd have to reset the UIDVALIDITY in order to recover.
Not likely to happen, otherwise that option wouldn't exist.
Clients, of course, have to deal with it as a 64-bit unsigned integer for all
That's a problem. If you don't have a 64-bit integer type available in
then compiler, then you have to do the work by hand. There seems to me to
be no good reason for this.
-- Mark --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.