[Standards] UPDATED: XEP-0237 (Roster Versioning)

Peter Saint-Andre stpeter at stpeter.im
Tue May 12 15:51:46 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/9/09 12:52 PM, Jiří Zárevúcký wrote:
> I have read the text again after a while and the following text got my
> attention:
> 
>> If a series of roster modifications result in a roster item that does not differ from the
>> version cached by the client (e.g., a modification to the item's 'name' attribute and
>> then a modification back to the original value), the server SHOULD NOT consider the
>> item to have been modified for purposes of roster versioning and therefore SHOULD NOT
>> push the item to the client in an interim roster push.
> 
> That part is not very useful, since servers will hardly keep track of
> every previous roster version. I don't even want to think about the
> CPU overhead that will kill the cluster every 30 minutes (that's a
> hyperbole of course). > The simplest "full featured" implementation
> consists of integer version numbers and "mver" field for every roster
> item. 

This is purely an implementation decision and I think we need to remove
the conformance language here (i.e., no MUST, SHOULD, SHOULD NOT, MAY).
If the server chooses the "hash complete roster" approach then it won't
send the push. If the server chooses the "integer version numbers"
approach then it will send the push. End of story.

> Server will then send all the items whose mver is greater than
> client's ver. Any throughout checking would hardly ever have any
> benefit.

What is mver?

> -----
> 
> About the opaque vs. integer examples dilemma. I think if someone
> really doesn't read the text, his implementation won't work at all
> anyway. The examples are kinda confusing this way. If you really want
> some opaque strings there, use "AAAAA", "BBBBB", "CCCCC" or something
> like that, so the sequentiality is obvious.

A sequence number is not really opaque, is it? The examples currently
use the "hash complete roster" approach. I would prefer to err on the
side of not misleading clients about sequentiality ("the examples have
AAAAA and BBBBB so I suppose the next 'ver' will be CCCCC" and then the
client breaks when that's not the case).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoJmxIACgkQNL8k5A2w/vxhegCglAtb65fUcXi2bohtzW82BpAS
G60AoJCWXtUiq7/9SwLGm7iWap1EKTin
=Z/nK
-----END PGP SIGNATURE-----




More information about the Standards mailing list