2009/4/17 Peter Saint-Andre <[email protected]>: > On 4/17/09 11:55 AM, Jiří Zárevúcký wrote: >> 2009/4/17 Peter Saint-Andre <[email protected]>: >>> On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: >>>> 2009/4/17 Peter Saint-Andre <[email protected]>: >>>>> 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.
