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...
