[Standards] UPDATED: XEP-0237 (Roster Versioning)
florian.zeitz at gmx.de
Thu May 14 17:42:31 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
Curtis King wrote:
>> 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...
> well said..
> 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.
Apparently not so well said, because what you make out of it seems to be
different from what I meant.
It is not in itself a problem that ver is opaque. Considering
futureproofness it is probably a good idea.
Notice that this is not about increasing numbers against hashes, but
increasing numbers against opaque values.
What I meant is that I can't see any real benefit in using something
different then numbers (especially hashes) (thanks Matthew for pointing
out a use-case BTW).
I personally think the way to go might really be putting r1, r2, ...
in the examples, as Matthew Wild suggested (Maybe use r<number> in
Example 3 and v<number> in Section 3, so we have different letters and
no-one tries to be clever). It fixes the problems hashes cause in this
place, yet enables you to see that the value is opaque from the examples.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards