2009/5/13 Jiří Zárevúcký <[email protected]>: > 2009/5/13 Waqas Hussain <[email protected]>: >> >> Programmers for whom ver='qAxdnWNcA+lYf7CoN5wpBsvVVno=' would be >> entirely impossible... I think those exact programmers are the reason >> for not using ver='1' :-) >> > > If it is a hash of a complete roster (as Peter has told) then the > server would have to decode this hash, figure out exactly what version > that was, create a difference, figure out the version for every > change, and send every change with the appropriate full roster > checksum again. I'm not that much into cryptography, and it depends on > the kind of hashing used, but if that possible, someone implementing > this would at least be completely out of his/her mind. >
There is no "decoding" a hash. It is used to give each version of the roster an "automatic" version number if you like. In almost all respects it is otherwise the same as incremental numeric versions. >> The XEP is short and clear. The 'ver' attribute is an opaque string >> for clients, and client programmers shouldn't care what it's value is. >> I don't see a problem here. >> > > XEP is short and clear and nobody will ever have any problem reading > it. Examples are way more confusing because of some theoretical idiot > that's implementing example and not the XEP. Do we really want to make > obscure examples because of people that are probably incapable of > implementing it at all? > Obscure? And so what if they implement the examples and not the text of the XEP? The examples are valid too you know :) I for one don't think that this particular issue warrants further discussion. The XEP is absolutely fine as-is. Matthew
