-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/09 4:31 PM, Jiří Zárevúcký wrote: > 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.
We don't design our protocols based on catastrophic software failures. Maybe the server has an internal flag that anything before version X of roster Y might be invalid. That's why the server developers get paid lots of money. >>> 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. If the client says it has roster version X and the server returns only a few roster pushes, which are inconsistent with the roster version that the human user sees in another client, then perhaps the user suspects that there is something very wrong and calls the sysadmin. I see this problem as quite rare. Perhaps we don't need to solve it in our protocol and instead deal with it at the human layer. Not everything needs a technical solution. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknucQQACgkQNL8k5A2w/vxcogCg+ptsmND6JxFfD3UAbw4TIaRk EXUAoPLOqYIEq+NgPDXD9XJ3W108Sibo =DP0x -----END PGP SIGNATURE-----
