Jiří Zárevúcký wrote: > All the user has to do is to delete clients cache, in case he notices > any inconsistency. Compared to the difficulty of solving such rare > cases on the protocol level, it is not so much problematic I guess.
The only "easy" solution I see is to have separate "base" version, e.g. date of creation version='0' or just random number that will create roster collision improbable. Anyway, I don't think that it worth do. I see following possible cases of version "collision": 1. Server crash If server has lost the roster the only thing that the client MAY do on receiving empty roster with ver="0" is to ask user if the user wants to save local cache instead of purging it. I really don't want to lose the roster because of server crash and I really would like to be able to restore it from local cache. Anyway, I'm not sure if the case should be mentioned in the XEP as it purely implementation-specific feature. 2. Same user unregister account and register it again. I see the only sane reason to do that — user wants to purge the roster and has no shortcut for that. I don't think that it is real-world case. 3. One user unregisters his account and another one registers one with same JID and password. The first user logs in with stale cache then. IMHO, this case is sort of soap opera scenario :-) -- WBRBW, Leonid Evdokimov
signature.asc
Description: OpenPGP digital signature
