2009/4/22 Peter Saint-Andre <[email protected]>: >> >> There could be another problem, though. If the roster got reverted, >> some client could update it up to the original sequence number or >> further. Then if some client that wasn't used for long time came >> online, it could receive wrong updates. > > I think it is up to the server to return the complete roster in this case. >
There would be no difference from an ordinary request. In this case the server has no way of knowing that the client's cache differs from the real current state. > >> Is such scenario worth attention? I don't know how often could >> something like that happen. The only way to fix it (I can think of) >> would be including some identifier of roster (another number?) that >> server would have to reset in case of any failure/reverting. The >> client would then send requests based on both roster's ID and sequence >> number. But I don't like the idea much. > > Yeah, I don't like that, either. Perhaps the solution is to use a better > server. :) > Well... that's probably truth :) But I don't think something like fail-proof server really exists... I'll need to think about it further.
