Re: MODSEQ in CONDSTORE

[Dave Cridland <dave@xxxxxxxxxxxx>]

On Thu Feb  2 00:46:03 2006, Mark Crispin wrote:
> 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.
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 
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 
64-bit.

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.


> > 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.
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 
is deficient.


> > 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.
Sure, but why make things worse?


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

Dave.
--
          You see things; and you say "Why?"
  But I dream things that never were; and I say "Why not?"
   - George Bernard Shaw