On Wed Mar 5 07:07:20 2008, Alexander Gnauck wrote:
Richard Dobson schrieb:
+1. I can't see any reason for the spec to require more than a
increasing version number.
I would prefer if it were just an opaque string, certainly as far
as the client in concerned there is no need for it to do anything
other than store the most recent version identifier it has
received and then return that to the server when required (i.e. at
login), only the server needs to know what to do with it and this
should certainly only be RECOMMENDED or SUGGESTED/MAYBE and not
MUST. What would happen in cases were the version number needs to
be reset to 0 because someone has such a busy roster that over
time they exhast the maximum integer value?, or if maybe in future
server implementors want to compress it somehow into hex or
something similar, it would be far far better to leave this
flexible and upto the server implementor on how they format the
version identifier.
yes I think we should recommend a an increasing integer. But should
allow any string. So if some server vendor prefers hash codes or
GUIDs for the versioning then this is fine for me too.
The only reason this scares me is that strictly increasing numeric
sequences have proved useful in the IMAP world, because clients can
spot when things go wrong much more easily.
Plus, nobody can get it wrong.
There's no way that even a 32-bit unsigned integer is going to
overflow - if you did an update every second, it'd take 136 years -
but if that still unnerves you (in case PSA turns into the undead, or
something), use a 64-bit unsigned 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
