Re: MODSEQ in CONDSTORE

[Dave Cridland <dave@xxxxxxxxxxxx>]

On Thu Feb  2 22:32:50 2006, Lisa Dusseault wrote:
> Dave said "the deficient server in this case causes no damage other 
>  than a spurious round-trip from a client.", and Mark said 
> something  about guns and preschoolers :)
Yeah. I'm talking specifically the case where a server increments a 
MODSEQ for a message when the message is not visibly changed. Which 
is the same as, for instance, a change to an ANNOTATion when the 
client doesn't speak ANNOTATE - the client isn't damaged by it as 
such, and has to expect it.

What would happen is that the client would see a changed 
HIGHESTMODSEQ, and accordingly issue a FETCH  ... CHANGEDSINCE, which 
would yield some response, which would provide data the client 
already had.

Where the HIGHESTMODSEQ is the same, the FETCH can be eliminated 
(and, optionally, even the SELECT).

Obviously the latter is more efficient and faster, and therefore a 
server which incremements the Modification sequence when no 
Modification has taken place is not as good as it could be.

Obviously the client will remain in sync without resorting to any 
kind of workaround - resync just happens to be more costly - so the 
server is not broken as such, and such behaviour could be the result 
of a modification the client is not capable enough to see.


> Were you two talking about different cases?  Would the outcome of 
> bad  client use of MODSEQ would be dire or simply the client's own 
> problem?

Mark's suggesting that, because all known uses of MODSEQ involve 
ignoring both its numeric nature and its status as a FETCH item, then 
it's potentially inviting doom by having MODSEQs have a numeric, 
ascending, per-message-accessible nature. This is a different case to 
the above. At least I think so.

I can't see this being the case - a client expecting some specific 
meaning to the difference of two MODSEQ numbers is probably asking 
for trouble (except in two vanishingly rare cases, where the 
difference is exactly 1), but for the most part, it won't cause any 
damage other than to itself, and potentially the user's data bill. 
Other clients I cannot see being affected by that, except 
beneficially.

You see, I could assume that an increment of 2 to HIGHESTMODSEQ 
implied there were two modifications, and having found two modified 
messages, I could decide that I'd found any modified messages, and 
consider myself resynchronized. Sometimes, I might even *be* 
resynchronized. Trouble is, any modification may encompass as many or 
few messages as possible, hence that's an invalid assumption, and the 
client may actually be out of sync. But, this doesn't effect another 
client. What can happen, however, is that the out of sync client can 
mark deleted, and subsequently expunge, the wrong message. But any 
out-of-sync client can do that perfectly well without CONDSTORE, and 
I don't think it makes the problem markedly worse.

You can cause wasteful round-trips for other clients by toggling a 
flag on and off across all messages, but I can't see this being done 
by accident much, and it merely degenerates CONDSTORE to uselessness, 
rather than actively breaking it.

I'm sure we'll eventually find a use for access to the MODSEQ of 
messages, probably something to do with archiving away old messages, 
or watching the changes to status of work items in a shared mailbox - 
I could probably come up with plenty of uses. I can't come up with 
much in the way of harm.

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