On Thu Mar 6 22:23:51 2008, Pedro Melo wrote:
Others might counter-propose something meaningful but some are
proposing something opaque, without meaning for the client. And
that is the best way for clients not to mess up.
Okay, I call. :-)
How *can* clients mess this up by knowing they can compare two values?
It's never, to my knowledge, been a problem in ACAP or IMAP, both of
which use something similar. It's been quite handy in IMAP CONDSTORE,
in fact.
The only particularly curious thing about integers is that it's
possible to note that, given two values, there's a maximum number of
changes that have happened between them. (But a fixed minimum of
zero, since the server's allowed to skip values). But even if a
client decides that the sequence values always change by one, and
only for a visible change, I can't see any possibility for a protocol
error. I'm not even sure what you'd do with that erroneous
information, but maybe I'm too used to dealing with these things.
So, please enlighten me - what is it that I'm missing?
Agreed. Hence a recommendation on implementation notes to use a
counter with those properties.
If clients did "mess it up", probably by testing against servers
using an integer, relying on it somehow, then finding servers with an
opaque string in the field, how much worse will the problem be? (See
Curtis's email for a very accurate account of how many
implementations get developed).
Either make it "really" opaque, if you have to, or else make it
clearly defined. So if you're going to remove the "integer" property,
then you'd best make it such that clients *cannot* compare it at all.
(Good luck with specifying that).
FWIW, I've said before that it's perfectly possible to map strictly
increasing modified timestamps to a strictly increasing integer. I'm
not dictating server internals - you can generate a strictly
increasing sequence value however you like, as long as you can map it
to an integer.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
