Re: MODSEQ in CONDSTORE

[Alexey Melnikov <alexey.melnikov@xxxxxxxxx>]

Dave Cridland wrote:

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

Indeed.

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

Exactly.

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

I concur.

[...]

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

Or one can use a struct with 2 32bit fields.