Re: MODSEQ in CONDSTORE

[Mark Crispin <mrc@xxxxxxxxxxxxxxxxxx>]

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

But that's only if (1) the mailbox has per-user flags, (2) the mailbox has 
MODSEQ.  Right?

Personally, I never thought that per-user flags were worth the complexity, 
even though I was guilty of creating them.  But it was only as a grim 
necessity for bboards and newsgroups; and even then that was just a single 
flag.  The idea of using MODSEQ for such a thing staggers me.

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

This argument only applies when you are monotonically allocating UIDs 
(otherwise it's your implementation that reduces the UID space, not 
MODSEQ).  And if you are monotonically allocating UIDs, then there is no 
reason not to monotonically allocate MODSEQ.  The notion of there being 
over 4 billion updates to one mailbox is simply not credible.

Now, if you have per-user and global flags in a mailbox that has MODSEQ, 
that may be a different matter.  But if you have that, that's a hole that 
you dug for yourself.  I see no reason to have such a thing; and if it was 
that important you should have defined two MODSEQs.

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

[sarcasm] And the IMAP community never, ever, produces broken clients and 
deficient servers (or deficient clients and broken servers). [/sarcasm]

We should have learned the painful lesson by now.

> > > 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? :-)

Sure, please write it.  And give it away for free, along with free 
technical support.

I have a difficult time tolerating the "my system has such-and-such, and 
it's your fault if your system does not have it too" attitude.  Either we 
care about interoperability and implementation costs, or we should forget 
this IETF nonsense and go home.

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

Are you certain?  IMHO, the client ability to fetch a message's MODSEQ 
directly is like placing a loaded pistol with a hair trigger in a room of 
preschoolers.  MODSEQ's ascending property makes it nice and shiny too.

Perhaps it would have been better to have created an alternative means to 
do those functionalities that doesn't leave temptation in the way.

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