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

Dave Cridland dave at cridland.net
Wed May 13 21:48:02 UTC 2009


On Wed May 13 20:11:22 2009, Florian Zeitz wrote:
> Just to have said it (in Pseudocode):
> Variant A:
> newVersion = getLargestVersionNumber() + 1;
> save(newVersion, roster);
> 
> Variant B:
> newVersion = sha1(roster);
> if !getRoster(newVersion): // check if this roster is already saved
>   save(newVersion, roster);
> 
> This is NOT way more difficult or anything.

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.

Can we rename this XEP, and avoid the usage of "version" everywhere?  
It seems this is causing lots of people considerable confusion.

It *is* possible to implement this XEP by actually storing each and  
every version, but this is utterly pointless, for a number of  
reasons, not least because the server won't ever need them.

Now, what Jiří is saying is that in the examples, we're  
illustrating what appears to be the method described in 5.2, but  
giving it the behaviour of an implementation using the method  
described in 5.3, whereas using a "pure" sequence value is simpler to  
understand.

I'm in two minds on this - I've commented before that I'd like to see  
some examples, especially those describing more complex cases, using  
the simple sequence values, since they're much easier to describe in  
supporting prose.

However, I'm mindful that this, too, is not an ideal implementation -  
I suggested in 5.3, fourth para a slightly better refinement - and  
there is the risk that a naïve client implementor may not realise  
that the examples are illustrative rather than exhaustive, and  
implement a client that expects integers only. 
Still, as long as not *all* examples show simple integer sequences, I  
think it might benefit some examples. (Perhaps Example 3, for  
instance).

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list