[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MODSEQ in CONDSTORE
On Thu Feb 2 00:46:03 2006, Mark Crispin wrote:
On Thu, 2 Feb 2006, Dave Cridland wrote:
A user setting \Seen (possibly implicitly in a FETCH BODY[...])
causes the MODSEQ to be bumped for that message. If the
implementation is poor, then this can cause the MODSEQ seen by other
users to be changed, too. That's undesirable, but as a client
implementor, I infinitely prefer that level of implementation to none
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.Sure, we could make it 34-bit and probably be safe. Even if you take
into account the private flags situation, and give yourself 15,000
users, you could get away with 42 bits. I think 64-bit is simply the
next logical choice above 32-bit. It needs *more* space than 32-bit,
how much more is rather moot, since the next logical size up is
Otherwise, you're effectively lowering the width of the UID space,
down to 30, or 22, bits. That's still probably plenty of space, but
there's something philosophically wrong about an extension lowering
the scalability of the protocol it extends.
Well, let me put it this way - a client which actually does care is
broken. A server which claims there to be a change when there is not
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.
Sure, but why make things worse?
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... :-(
Get a better compiler? :-)
FWIW, I strongly suspect I could get away with using the textual
representation of the MODSEQ/HIGHESTMODSEQ throughout my
implementation. It'd waste 36 octets, which is a figure I can live
with. (Probably more likely to be 74 octets including string handling
overhead, but that's still well within my tolerance - the code
overhead of parsing and formatting them would be much higher).
I don't believe clients ever need to handle more than 3 MODSEQ values
at any time, and only need to store 2 permanently. If I needed to
store each message's MODSEQ, I'd probably feel differently, but I
don't think that's ever the case.
Servers, of course, need to store at minimum one for every message
plus one for the mailbox, but as I've said, they can use a 32-bit
value if they prefer.
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw