[Standards] Proposed XMPP Extension: Roster Versioning
dave at cridland.net
Wed Mar 5 08:51:35 UTC 2008
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 Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards