2009/4/17 Peter Saint-Andre <[email protected]>: > On 4/17/09 11:59 AM, Jiří Zárevúcký wrote: >> 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. > > 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 > >
We definitely got out of sync. Such holding back of version isn't needed and is impossible if we are to use the way Dave proposed and I agreed with. Now to be completely clear, a little use case: (based on the current spec) However, if returning the complete roster would use more bandwidth than sending individual roster pushes to the client (e.g., if the roster contains many items, only a few of which have changed), the server SHOULD return an empty IQ result, then send individual roster pushes. Example 4. Roster result with no content <iq from='[email protected]' id='r1' to='[email protected]/home' type='result' /> Example 5. Server sends any changes since the clients state as ordinary pushes <iq from='[email protected]' id='p1' to='[email protected]/home' type='set'> <query xmlns='jabber:iq:roster' ver='313'> <item jid='[email protected]' subscription='remove'/> </query> </iq> <iq from='[email protected]' id='p2' to='[email protected]/home' type='set'> <query xmlns='jabber:iq:roster' ver='317'> <item jid='[email protected]' subscription='both'/> </query> </iq> The client can't figure out which push is the last change, but that doesn't matter, since all pushes are atomic. To rule out several possible corner cases, server MUST always send pushes for every changed item, even if there were several changes that in fact reverted itself. That means the server MUST NOT send a simple difference, but instead MUST send all the items that were modified at any point in history. --------------------- Now we are hopefully resynced and can talk about the same problem again.
