On 4/17/09 12:15 PM, Jiří Zárevúcký wrote: > 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.
Maybe we are back in sync. I think I processed some incremental protocol versions but not all of them, then I got mentally disconnected. ;-) I'll reply again once I've grokked the (seeming) consensus. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
