On 4/17/09 11:59 AM, Jiří Zárevúcký wrote: > 2009/4/17 Peter Saint-Andre <stpe...@stpeter.im>: >> On 4/17/09 11:55 AM, Jiří Zárevúcký wrote: >>> 2009/4/17 Peter Saint-Andre <stpe...@stpeter.im>: >>>> On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: >>>>> 2009/4/17 Peter Saint-Andre <stpe...@stpeter.im>: >>>>>> On 4/17/09 9:57 AM, Peter Saint-Andre wrote: >>>>>>> On 4/17/09 8:18 AM, Leonid Evdokimov wrote: >>>>>>>> Jiří Zárevúcký wrote: >>>>>>>>> I guess the only "issue" now is the unneeded restriction you added to >>>>>>>>> the SVN based on my incorrect feedback. I mean the part "The client >>>>>>>>> MUST NOT process any of the interim roster pushes until...". I think >>>>>>>>> you can safely remove it again, as the reason for the change was >>>>>>>>> proven invalid. >>>>>>>> No, that's quite valid restriction. Client MAY cache some roster pushes >>>>>>>> to resume operation from the middle of "transaction" in case of broken >>>>>>>> connection, but it MUST NOT bump it's internal roster version until it >>>>>>>> gets the full "transaction" of pushes. >>>>>>> That seems right to me. I think we just need to change "process" to >>>>>>> something else (you can process the push, but don't think that you are >>>>>>> up to date until you receive the last one). >>>>>> How is this text? >>>>>> >>>>>> "The client can determine when the interim roster pushes have ended by >>>>>> comparing the version number it received on the empty <query/> element >>>>>> against the version number it receives in roster pushes. The client MUST >>>>>> process the interim roster pushes as it would process any normal roster >>>>>> push and MAY cache those items in case it loses its connection to the >>>>>> server during the update process, but MUST NOT increment its internal >>>>>> roster version until it receives the full set of pushes." >>>>>> >>>>> Waitaminit... Didn't we agree that treating interim pushes the same >>>>> way as normal ones is the best approach? Otherwise we yet need to >>>>> solve the empty roster case somehow. >>>> Processing them means you handle them as normal. Just don't think that >>>> you are completely up to date until you receive the last one. >>>> >>> Ok... now I definitely don't follow... processing them as normal also >>> means you won't know what the last one it... and we agreed (at least >>> with Dave) we don't need to know that anyway... >> For the purposes of Roster Versioning, you MUST NOT think that you are >> up to date if you've received only some of the roster pushes. What is >> not clear about that? >> > > That it contradicts the "treat as normal" statement. Client is always > as up-to-date as the version number of the last push it processed. > There is no up-to-date state. There is just client's roster version.
You treat the roster push itself as normal -- update your local version of the roster, update your local presence database if appropriate, change the cute little icon in the GUI that shows the subscription state, and whatever all else you care about. But because you are a client that knows about roster versioning, you don't yet modify the internal counter that keeps track of which roster version is the most recent -- so in our example you still think that you have version 299, not 307 or whatever the numbers are. If you then get disconnected before you receive the roster push that matches the last version number that the server communicated to you, you request the version number that you have in your local counter (e.g., 299). Once you receive 307, you change the counter from 299 to 307. What is unclear? /psa
smime.p7s
Description: S/MIME Cryptographic Signature
