Re: MODSEQ in CONDSTORE

[Mark Crispin <mrc@xxxxxxxxxxxxxxxxxx>]

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 
> servers.

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 --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.