On Thu Mar 6 07:50:32 2008, Justin Karneges wrote:
What counts as what is a matter of what the usual design practices
and trends are for related specifications. My assessment, from
what I read in the mailing list arguments, is that opaque was in
the 'neutral' category. Thus it should not be Richard that needs
to argue for opaque, but rather it should be Dave that needs to
argue for integer. IMO, I guess.
*sigh*
I wouldn't put my name to it, but I suspect that merely "unique" is
sufficient to avoid breakage in the client, although it'll produce a
fairly inefficient protocol, equivalent to a simple
"get-if-none-match".
It's possible - but again, I wouldn't put my name to it - that
"strictly non-decreasing" is okay, too. I'm a lot less sure about
this, I've not thought too hard about the failure cases. I think this
would yield inefficiency, too, but I think it might not break
anything. Perhaps.
For efficiency, then, you need a strictly increasing sequence, which
has the useful property that it's known to work in several use-cases
now.
Now, potentially, this need not be a non-negative integer sequence,
but non-negative integer sequence is, by far, the simplest one to
implement, and has the convenient property that we know where it
starts. They're a lot easier to implement than a modified strictly
increasing timestamp. (I know, I've done both).
There's the other advantage that strictly increasing integer
sequences are very well understood, having been used in various
places for a couple of decades for synchronization in network
protocols. (The IMAP UID[NEXT] is one such, as is the more recent
[HIGHEST]MODSEQ, used in real deployments. ACAP used a strictly
increasing timestamp-derived value, and this is not only more
complicated to increment, it's also slower, mandating a system call
in addition to the contention point, and is nightmarishly difficult
to explain clearly in a specification, and finally, it's not really
quite an integral value, and instead needs comparing as a string, not
an int)
Now - should a client be able to compare two sequence values and see
which one is higher? If so, we want a clearly defined sequence, if
not, we don't care.
Well, this has been the case for IMAP UIDs for years, and is
remarkably handy in this particular instance, but that's unfair -
UIDs are, by intent, designed for this.
IMAP CONDSTORE was long thought to be able to be implemented in the
client as pure strings. My own client implementation does actually
compare values in a few cases for efficiency - and I'm only doing the
synchronization side of CONDSTORE, which is equivalent to what we're
doing here. I'd hate to discover late in the day that we actually
need to do this.
The assertion that by allowing client-side comparison of sequence
values it's possible to introduce bugs is an interesting one, but as
far as I can tell, baseless - it's yet to cause a problem in IMAP
CONDSTORE or ACAP modtime, and indeed has actually been a bit of a
benefit. Still, I'd be happy if there were a directive that clients
SHOULD NOT compare locally.
One case where client-side comparison of sequence values is very
useful indeed is for external testing - it makes it much easier when
you can perform simple verification. Recently, we've seen an upsurge
in wire-based external testing/validation tools in IMAP, and they've
proven very useful for server developers.
So I'd lean toward "does no harm", and "can be useful in some
circumstances", and therefore we need a well-defined strictly
increasing sequence.
There are many such sequences, however, but the one that strikes me
as most useful is an integral one. Life because even easier when we
know of a particular value which is lower than or equal to all others
in the sequence, too.
So, in conclusion, I'll stick to my guns and say we want a strictly
increasing integer sequence.
> "One interesting point is that with an int, there's always
something a
> client can use to get the entire roster, with versioning turned
on."
>
> "I'm not quite sure what the client ought to send if everything's
> completely opaque - it'd need more syntax."
Maybe these could be explained here on the list. The implication
in these statements is that the revision value has meaning to the
client, and that the client can even create these values.
Yes, it can, in one case - where it wishes to specify a sequence
value that occurs prior to all others. Clients use this in the spec
as written to request all updates from a sequence value lower than,
or equal to, all possible sequence values.
(This does, to be fair, break pre-populated rosters in a naïve
implementation - if your server does prepopulated rosters, like
shared rosters, you'll need to update the sequence when you
[pre-]populate externally.)
We can do this bootstrapping in two ways. Either a special attribute
value is chosen which has the fixed property of comparing equal to or
lower than any valid value of the sequence, or else we signal this
using a different attribute.
With an integer sequence, you can choose "0". We could also force the
sequence to begin with "1" - a non-zero non-negative strictly
increasing integral sequence - which'd help those servers which
prepopulate rosters.
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
