A few hours of testing does not a reliable protocol make. Under what
conditions? Is this a public server that people can test against?
No you are correct, but even so the tone of some of the messages on this
subject as far as I read them said that it wouldn't work, and under my
limited testing it does seem to. I can make it publically accessible if
you like and actually want to and will have a go.
I'm not convinced that that's the intent. It seems that it might be
useful in some situations for the client to know where it stands.
Then id suggest that gets specified in the spec.
We do need technologies that won't break.
Sure but it hasn't been fully explained why it would break.
"It's a lot more efficient with an int, and everything else is either
worse performance, fails entirely, or else is equivalent difficulty to
an int."
What sort of things are these? Im not trying to say im right and he's
wrong but id like a more full explanation on the points above and below
so I can understand why Dave thinks it will break, because as far as I
can see all the problems pointed out so far in this thread can be easily
overcome.
"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."
Yea it can just omit the version attribute.
"I'm not quite sure what the client ought to send if everything's
completely opaque - it'd need more syntax."
What kind of syntax were you thinking of?
"Put it this way, since the counter-proposal involved timestamps, which
are known to be broken, I'm pretty sure people will get stuff wrong
without it being a MUST."
Why are they broken?
And previously on the list he said [2]:
"strictly increasing numeric sequences have proved useful in the IMAP
world, because clients can spot when things go wrong much more easily."
Ok thats certainly fair enough, although it would be good to specify
that in the spec.
And [3]:
"You can't use timestamps - they're not strictly increasing, for
various reasons.
Why does it have to be strictly increasing, even if it was a timestamp?
Firstly, two roster changes could happen at precisely the same
moment. To be fair, by introducing cluster node identifiers, and
having a strict strong ordering of them, you could avoid this.
Why is it a problem if two updates share the same version identifier?
Couldn't they not just become part of a single atomic change?
Secondly, the clock on a computer can, and surprisingly often does,
go backwards. That's a much harder problem to solve.
As previously requested could you describe this further or point to some
more information on this so I can understand how much of a problem this
actually is.
Thirdly, in a clustering situation, you'd have to ensure that the
time on each cluster node was perfectly synchronized.
No they don't as previously pointed out (the database layer could
generate all the ids).
So the closest you can do would be a modified timestamp that had
additional logic during generation to ensure it never went backwards,
in which case you don't need the cluster identifier anymore, and
that's effectively the same as having a strictly increasing integer
sequence anyway, so it's easier to just do that. But even if you did
want to use timestamps, just representing them as an integer is
pretty trivial. Look at the definition of "modtime" in ACAP (RFC
2244), which defines a strictly increasing modified timestamp
represented using digits."
Yup exactly so the issue about clocks going backwards can be easily
overcome then.
I don't see that these concerns were addressed on the list. And I don't
see this as an appeal to authority or nannyism, just heeding the voice
of experience.
I did respond similar to above, but didn't see any response to my
questions, I would appreciate some answers so I can at least understand
where Dave is coming from.
Is there any chance we can use BASE64 or something to compress the
version identifiers in the roster pushes and whatnot?, just like is done
with the hashes in caps? Or do we think its probably not really going to
be a problem in the future? Granted as an auto incrementing integer it
probably wont be much of an issue unless you have an incredibly busy
roster, just trying to plan ahead.
Richard
