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

Matthew Wild mwild1 at gmail.com
Thu May 14 11:59:17 UTC 2009

On Thu, May 14, 2009 at 12:40 AM, Florian Zeitz <florian.zeitz at gmx.de> wrote:
> Hash: SHA1
> Dave Cridland wrote:
>> Yes it is, and it's also a terrible idea, since the server would then
>> have an ever increasing number of versions, many of which would never be
>> requested by the client, and likely none of which would be needed in
>> entirety.
> As I found this a rather harsh response I reread the XEP very thoroughly
> (I suspect my last read was also a few revisions back) and I have to say
> I'm pretty baffled.
> (In my defence though the idea I had in mind was to only keep rosters
> for a certain amount of time, or only a limited number, which I deemed
> out of scope for the pseudocode)

Ok, I must admit that I'm still not entirely sure what all the fuss is about :)

> I agree with Jiří Zárevúcký and Dave Cridland by now.
> Most examples should have numbers. Example 3 because it makes it easier
> to read. And Section 3 Examples, because 5.3 says so.
> I'm also not really sure why anyone might ever want to use hashes. The
> only upside is that in the all or nothing use-case (5.2) you don't have
> to save any version, because you can compute it. But a) it is still more
> or less recommended to save the hash for performance gain b) saving an
> additional stricty increasing integer would work as well and be smaller
> than a hash.
> I unfortunately missed out on the discussion about making ver opaque,
> but the result doesn't seem plausible to me right now...

> I guess it is not a bad idea to define ver as opaque, but recommending
> hashes, or anything other than integers just doesn't seem worthwhile...

I thought the whole point of making ver opaque was that we don't
recommend anything, but leave the choice up to server developers.

With integer versions there is the risk of a client developer
mistakenly interpreting ver as always being an integer, or worse,
always being strictly increasing, etc.

>From what I understand, the argument is as follows:

1) Hashes are too hard to implement
2) Hashes in the examples make the examples too hard to follow


1) Integers in the examples may mislead implementors regarding
    the opacity of 'ver'

As a compromise how about making the ver in the examples something
like: 'r1', 'r2', 'r3'. Possibly changing 'r' in each example, just to
be absolutely certain :)

At the end of the day, as I have said before, I'm not really fussed
either way. I think we should give developers more credit, they aren't
all incapable of reading specifications.


More information about the Standards mailing list