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.
