2009/5/13 Jiří Zárevúcký <zarevucky.j...@gmail.com>: > 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. > I don't think so. Using hashes is quite practical. It wouldn't be much more complicated than using sequence numbers in fact, and not inefficient either. Depending on the implementation, the server itself can treat the ver value as opaque, except for when it is computing a new one (which is a relatively rare operation). Think about it more, and feel free to talk to me if you can't see how.
>> 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? > I for one don't see the examples as obscure at all. -- Waqas Hussain
