[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MODSEQ in CONDSTORE
On Thu, 2 Feb 2006, Dave Cridland wrote:
If you make UIDs 32-bit, then you have to allow for more space in something
expected to have more than one increment per UID. Moreover, this gives enough
space for poor implementations to show MODSEQ changes from users' private
flags. It's not ideal, but it's better than having no CONDSTORE at all.
I don't understand this statement at all.
Both UIDs and sequence numbers are also 32-bit. I don't see what is so
special about MODSEQ that it needs 9 orders of magnitude more value space.
A typical message gets its flags changed fewer than 4 times.
If you mean setting a flag where the flag is already set, then from a
practical standpoint it simply doesn't matter if the MODSEQ for the message
is bumped or not. It's much better if it isn't, but it doesn't break anything
if it is.
I disagree. Either MODSEQ reports that something touched the message, or
it reports that something changed the mesage. As matters stand, it is
ambiguous. A client may care.
Not very likely, no. But equally, it's not very likely that you'd overflow
UIDs, but that option is handled by the protocol. If it were an onerous
thing, I'd worry about it, but it's really not.
But the same mechanism resets the MODSEQ as well.
Well, I don't think it's much of a problem. Most of the computers I work with
these days increasingly use "unsigned long" for 64-bit values - even my
laptop is 64-bit, but the vast majority of the 32-bit systems I use seem to
support some kind of "unsigned long long" or equivalent.
That hasn't been my experience... :-(
-- 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.