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

Matthew Wild mwild1 at gmail.com
Thu May 14 17:04:48 UTC 2009

On Thu, May 14, 2009 at 5:29 PM, Curtis King <cking at mumbo.ca> wrote:
> On 13-May-09, at 4:40 PM, Florian Zeitz wrote:
>> I'm also not really sure why anyone might ever want to use hashes.
> +1

Can't you let us (the server developers) decide that? ;)

A reason for why one might use hashes is (as was pointed out) to save
having to store roster version information. This *is* actually a
concern to us. We have plans to support ejabberd's database schemas in
Prosody, essentially allowing you to switch from ejabberd to Prosody
with no data migration necessary.

ejabberd doesn't support roster versioning, and so we would have had
to disable versioning when using ejabberd's schemas. However if we can
now fall back to using hashes, it means that we *can* still support
versioning while running in these conditions.

> In addition it makes the XEP more complex as you now have two possible
> implementation choices to understand. One is always simpler than two ;-)
> Having a single simple notification method is best for interoperability and
> it doesn't get simpler than a strictly increasing integer. If these long
> discussion about the fallout of adding hashes haven't proved it I don't what
> would.
> I vote to remove hashes from the XEP and only specify integers.

First things first... the XEP doesn't specify any method over the
other. Yes, it gives implementation guidelines, but at the end of the
day the choice is up to the implementor. If server developers want to
use hashes, why not let them?

The way I read your email you want to remove the ability to use
hashes, which implies making 'ver' not opaque to the client, and I can
only ask what benefits having the client be able to interpret 'ver'


More information about the Standards mailing list