[Standards] Proposed XMPP Extension: Roster Versioning

Richard Dobson richard at dobson-i.net
Wed Mar 5 11:00:34 UTC 2008

> 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.

> Sometimes flexibility comes back to bite you. I'd prefer to keep things
> simple if we can. What does the extra flexibility really do for us, and
> is it worth the cost?
Well I think it is better to be flexible in this case otherwise its 
forcing server implementors to implement this in a particular way when 
there is no real need to, what if in a particular implementation its 
more efficient to implement it as GUIDs for example as Alex suggested 
because of how its clustered or how the database is implemented, in my 
case id want to implement this as a compressed timestamp rather than as 
an increasing integer, and as far as the spec is currently written and 
how it would work for clients it wouldn't make any difference what the 
version identifier is as it isn't (and IMO MUST NOT) take any meaning 
from the value of the version identifier so things stay nice and simple, 
as as soon as clients start taking any meaning of what the version 
identifier means you are introducing a whole raft of potential 
interoperability issues and bugs that need not exist.

> 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.
I think this its a very very bad idea for the clients to take any 
meaning from the version identifier as explained above, its just opening 
a pandora's box of potential bugs and issues, far better for it to just 
be a opaque string as far as the client in concerned, which also helps 
to keep things as simple as possible.

> Plus, nobody can get it wrong.
How exactly are they going to get it wrong if its an identifier that 
only the server is interpreting the meaning of?

> 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.
Its possible even if unlikely, what if several updates were made in one 
second because of some kind of bulk update for example, at the very 
least the spec MUST define what should happen if the number is going to 
overflow, i.e. reseting to 0, even though it is unlikely.


More information about the Standards mailing list