On Thu, May 14, 2009 at 5:29 PM, Curtis King <[email protected]> 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' brings? Matthew.
