Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 2:08 PM, Leonid Evdokimov wrote: > Jiří Zárevúcký wrote: >> Example 4. Roster result with no content >> >> > type='result' /> >> >> Example 5. Server sends any changes since the clients state as ordinary >> pushes >> >> > type='set'> >> >> >> >> >> >> > type='set'> >> >> >> >> >> >> >> The client can't figure out which push is the last change, but that >> doesn't matter, since all pushes are atomic. Right. > «Example 2. Roster result (unchanged)» equals «Example 4. Roster result > with no content». Yes, I understand that it's ok to send same reply in > both cases as it has following semantics: «roster updates (if any) will > be sent as subsequent roster pushes». > > The client can't figure out which push is the last change, so it can't > send initial presence after receiving up-to-date roster as client never > knows if it is up-to-date. I don't know if that really matters, but that > interferes a bit with RFC3921: > > | 7.3. Retrieving One's Roster on Login > | > | Upon connecting to the server and becoming an active resource, a > | client SHOULD request the roster before sending initial presence > | (however, because receiving the roster may not be desirable for all > | resources, e.g., a connection with limited bandwidth, the client's > | request for the roster is OPTIONAL). > > So client SHOULD request roster and send initial presence without > waiting for the roster to came. Yes, same as it has always been (at least since I've been involved in the Jabber/XMPP community!). >> 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. > > Right, that's exactly what I called "rsync-way". Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
Jiří Zárevúcký wrote: > Example 4. Roster result with no content > > type='result' /> > > Example 5. Server sends any changes since the clients state as ordinary pushes > > > > > > > > > > > > > > > The client can't figure out which push is the last change, but that > doesn't matter, since all pushes are atomic. «Example 2. Roster result (unchanged)» equals «Example 4. Roster result with no content». Yes, I understand that it's ok to send same reply in both cases as it has following semantics: «roster updates (if any) will be sent as subsequent roster pushes». The client can't figure out which push is the last change, so it can't send initial presence after receiving up-to-date roster as client never knows if it is up-to-date. I don't know if that really matters, but that interferes a bit with RFC3921: | 7.3. Retrieving One's Roster on Login | | Upon connecting to the server and becoming an active resource, a | client SHOULD request the roster before sending initial presence | (however, because receiving the roster may not be desirable for all | resources, e.g., a connection with limited bandwidth, the client's | request for the roster is OPTIONAL). So client SHOULD request roster and send initial presence without waiting for the roster to came. > 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. Right, that's exactly what I called "rsync-way". -- WBRBW, Leonid Evdokimov signature.asc Description: OpenPGP digital signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 1:01 PM, Jiří Zárevúcký wrote: > 2009/4/17 Jiří Zárevúcký : >> 2009/4/17 Peter Saint-Andre : >>> On 4/17/09 12:48 PM, Peter Saint-Andre wrote: On 4/17/09 12:43 PM, Jiří Zárevúcký wrote: > 2009/4/17 Leonid Evdokimov : >> ... >> >> So the first method works like trivial VCS and the second one works like >> rsync or incremental tar. What method is actually described in the XEP ? >> Seems, that will also answer Jiří's question about `treat as normal` >> statement. >> > The general idea of this thread is to say what should XEP actually > describe, right? ;) Can you please comment my example? I'd like to > know what you think. I *think* we have consensus, but I'm still pondering it. I will update the spec accordingly to make sure that I understand it. >>> Before I get too far in the spec updates, here is an example. >>> >>> Client thinks version is 299. Server thinks it is 309. To simplify, >>> consider every odd version number to be significant (the server will be >>> pushing 301, 303, 305, 307, 309). So: >>> >>> C: IQ-get [299] >>> S: IQ-result >>> S: push [301] >>> S: push [303] >>> S: push [305] >>> >>> C: IQ-get [305] >>> S: push [307] >>> S: push [309] >>> >>> Yes? >>> >> That's right. >> > > But you forget the second IQ-result. :) Well, sure, typed it up fast. :P smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Jiří Zárevúcký : > 2009/4/17 Peter Saint-Andre : >> On 4/17/09 12:48 PM, Peter Saint-Andre wrote: >>> On 4/17/09 12:43 PM, Jiří Zárevúcký wrote: 2009/4/17 Leonid Evdokimov : > ... > > So the first method works like trivial VCS and the second one works like > rsync or incremental tar. What method is actually described in the XEP ? > Seems, that will also answer Jiří's question about `treat as normal` > statement. > The general idea of this thread is to say what should XEP actually describe, right? ;) Can you please comment my example? I'd like to know what you think. >>> >>> I *think* we have consensus, but I'm still pondering it. I will update >>> the spec accordingly to make sure that I understand it. >> >> Before I get too far in the spec updates, here is an example. >> >> Client thinks version is 299. Server thinks it is 309. To simplify, >> consider every odd version number to be significant (the server will be >> pushing 301, 303, 305, 307, 309). So: >> >> C: IQ-get [299] >> S: IQ-result >> S: push [301] >> S: push [303] >> S: push [305] >> >> C: IQ-get [305] >> S: push [307] >> S: push [309] >> >> Yes? >> > > That's right. > But you forget the second IQ-result. :)
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre : > On 4/17/09 12:48 PM, Peter Saint-Andre wrote: >> On 4/17/09 12:43 PM, Jiří Zárevúcký wrote: >>> 2009/4/17 Leonid Evdokimov : ... So the first method works like trivial VCS and the second one works like rsync or incremental tar. What method is actually described in the XEP ? Seems, that will also answer Jiří's question about `treat as normal` statement. >>> The general idea of this thread is to say what should XEP actually >>> describe, right? ;) Can you please comment my example? I'd like to >>> know what you think. >> >> I *think* we have consensus, but I'm still pondering it. I will update >> the spec accordingly to make sure that I understand it. > > Before I get too far in the spec updates, here is an example. > > Client thinks version is 299. Server thinks it is 309. To simplify, > consider every odd version number to be significant (the server will be > pushing 301, 303, 305, 307, 309). So: > > C: IQ-get [299] > S: IQ-result > S: push [301] > S: push [303] > S: push [305] > > C: IQ-get [305] > S: push [307] > S: push [309] > > Yes? > That's right.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 12:48 PM, Peter Saint-Andre wrote: > On 4/17/09 12:43 PM, Jiří Zárevúcký wrote: >> 2009/4/17 Leonid Evdokimov : >>> ... >>> >>> So the first method works like trivial VCS and the second one works like >>> rsync or incremental tar. What method is actually described in the XEP ? >>> Seems, that will also answer Jiří's question about `treat as normal` >>> statement. >>> >> The general idea of this thread is to say what should XEP actually >> describe, right? ;) Can you please comment my example? I'd like to >> know what you think. > > I *think* we have consensus, but I'm still pondering it. I will update > the spec accordingly to make sure that I understand it. Before I get too far in the spec updates, here is an example. Client thinks version is 299. Server thinks it is 309. To simplify, consider every odd version number to be significant (the server will be pushing 301, 303, 305, 307, 309). So: C: IQ-get [299] S: IQ-result S: push [301] S: push [303] S: push [305] C: IQ-get [305] S: push [307] S: push [309] Yes? /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 12:43 PM, Jiří Zárevúcký wrote: > 2009/4/17 Leonid Evdokimov : >> ... >> >> So the first method works like trivial VCS and the second one works like >> rsync or incremental tar. What method is actually described in the XEP ? >> Seems, that will also answer Jiří's question about `treat as normal` >> statement. >> > > The general idea of this thread is to say what should XEP actually > describe, right? ;) Can you please comment my example? I'd like to > know what you think. I *think* we have consensus, but I'm still pondering it. I will update the spec accordingly to make sure that I understand it. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Leonid Evdokimov : > ... > > So the first method works like trivial VCS and the second one works like > rsync or incremental tar. What method is actually described in the XEP ? > Seems, that will also answer Jiří's question about `treat as normal` > statement. > The general idea of this thread is to say what should XEP actually describe, right? ;) Can you please comment my example? I'd like to know what you think.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 12:15 PM, Jiří Zárevúcký wrote: > 2009/4/17 Peter Saint-Andre : >> On 4/17/09 11:59 AM, Jiří Zárevúcký wrote: >>> 2009/4/17 Peter Saint-Andre : On 4/17/09 11:55 AM, Jiří Zárevúcký wrote: > 2009/4/17 Peter Saint-Andre : >> On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: >>> 2009/4/17 Peter Saint-Andre : 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 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 > > type='result' /> > > > Example 5. Server sends any changes since the clients state as ordinary pushes > > > > > > > > > > > > > > > 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. > > > ---
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
Peter Saint-Andre wrote: > "The client can determine when the interim roster pushes have ended by > comparing the version number it received on the empty 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." As far as I see, caching may be easily done only in case when "the result" is not "the difference between two states", but "final state of all roster items touched between two states". Otherwise caching of the items is quite useless as the client would have to rerequest same items on reconnection to avoid the corner-case presented above. Please, clarify "the final result" in the phrase "The interim roster pushes would not include all of the intermediate steps, only the final result of all changes applied while the client was in fact offline". If the result if the difference: * client must not cache items (it's useless) * server may have to store all roster versions to produce proper diffs (at least I see no other way right now, maybe I'm wrong) If the result if set of touched roster items: * client MAY increment his roster version counter while processing items. Yes, client will not know if his counter reflects "real" roster version, but client will know that (a) he is/isn't up to date (b) roster item mr@example.org was/wasn't modified since version 42 and that's enough for continuing incremental update in case of broken connection. * server has to store only "mtime" of every roster item (including deleted?) So the first method works like trivial VCS and the second one works like rsync or incremental tar. What method is actually described in the XEP ? Seems, that will also answer Jiří's question about `treat as normal` statement. -- WBRBW, Leonid Evdokimov signature.asc Description: OpenPGP digital signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre : > On 4/17/09 11:59 AM, Jiří Zárevúcký wrote: >> 2009/4/17 Peter Saint-Andre : >>> On 4/17/09 11:55 AM, Jiří Zárevúcký wrote: 2009/4/17 Peter Saint-Andre : > On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: >> 2009/4/17 Peter Saint-Andre : >>> 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 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 Example 5. Server sends any changes since the clients state as ordinary pushes 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.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 11:59 AM, Jiří Zárevúcký wrote: > 2009/4/17 Peter Saint-Andre : >> On 4/17/09 11:55 AM, Jiří Zárevúcký wrote: >>> 2009/4/17 Peter Saint-Andre : On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: > 2009/4/17 Peter Saint-Andre : >> 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 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre : > On 4/17/09 11:55 AM, Jiří Zárevúcký wrote: >> 2009/4/17 Peter Saint-Andre : >>> On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: 2009/4/17 Peter Saint-Andre : > 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 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.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 11:55 AM, Jiří Zárevúcký wrote: > 2009/4/17 Peter Saint-Andre : >> On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: >>> 2009/4/17 Peter Saint-Andre : 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 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? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre : > On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: >> 2009/4/17 Peter Saint-Andre : >>> 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 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...
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 11:51 AM, Jiří Zárevúcký wrote: > 2009/4/17 Peter Saint-Andre : >> 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 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. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre : > 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 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.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
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 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." Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 10:21 AM, Leonid Evdokimov wrote: > Jiří Zárevúcký wrote: >>> Let's assume that connection was broken and client got 307 but not 308, >>> client does not know version 307 at the moment, as it *does* *not* know >>> that bill@ has subscription="to". That's why I name the set of stanzas a >>> "transaction" and that's why I'm against of processing interim roster >>> pushes until client has received all pushes. >> That's what I was talking about earlier, isn't it? > > Excuse me, I misread your original message. You're right, that's exactly > the same situation. > > >>> XEP-0237 does not state that server should send "final state of all >>> touched roster items", it should send "the final result of all changes >>> applied" and the result may be understood as the difference. >> that's also the reason for the ultra-rare corner case I posted earlier. >> >> Changing the definition to "final state of all touched roster items" >> as you suggest will solve every possible problem and allow us to treat >> interim pushes as normal ones. > > Right, it will also eliminate the problem with empty difference between > two roster versions — the difference will be always non-empty. I think this works well. > This solution increases amount of traffic a bit, but I don't think that > the corner case really deserves extra optimization. Agreed. I'm working to update the spec now... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
Jiří Zárevúcký wrote: >> Let's assume that connection was broken and client got 307 but not 308, >> client does not know version 307 at the moment, as it *does* *not* know >> that bill@ has subscription="to". That's why I name the set of stanzas a >> "transaction" and that's why I'm against of processing interim roster >> pushes until client has received all pushes. > > That's what I was talking about earlier, isn't it? Excuse me, I misread your original message. You're right, that's exactly the same situation. >> XEP-0237 does not state that server should send "final state of all >> touched roster items", it should send "the final result of all changes >> applied" and the result may be understood as the difference. > > that's also the reason for the ultra-rare corner case I posted earlier. > > Changing the definition to "final state of all touched roster items" > as you suggest will solve every possible problem and allow us to treat > interim pushes as normal ones. Right, it will also eliminate the problem with empty difference between two roster versions — the difference will be always non-empty. This solution increases amount of traffic a bit, but I don't think that the corner case really deserves extra optimization. -- WBRBW, Leonid Evdokimov signature.asc Description: OpenPGP digital signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Leonid Evdokimov : > Dave Cridland wrote: >>> 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. >> >> We decided that each roster push was in and of itself atomic, so the >> "transaction" you're referring to doesn't exist - each roster push can >> be effectively treated as an atomic commit point in and of itself. > > I still think it exists, let me explain my point of view more precisely. > > Here is set of versions: > > > > > > > > > > > > > > > > > > Client knowns 305, current version is 308. The server will send 307, 308 > and the notification that the latest version is 308. > > Let's assume that connection was broken and client got 307 but not 308, > client does not know version 307 at the moment, as it *does* *not* know > that bill@ has subscription="to". That's why I name the set of stanzas a > "transaction" and that's why I'm against of processing interim roster > pushes until client has received all pushes. > That's what I was talking about earlier, isn't it? > > XEP-0237 does not state that server should send "final state of all > touched roster items", it should send "the final result of all changes > applied" and the result may be understood as the difference. > > Am I mistaken somewhere? > No, that's also the reason for the ultra-rare corner case I posted earlier. Changing the definition to "final state of all touched roster items" as you suggest will solve every possible problem and allow us to treat interim pushes as normal ones.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre : > > We can't send an IQ-result that's unrelated to any IQ-set or IQ-get. > I was thinking more like this: Client sends IQ get. Server sends interim pushes. Server sends empty result to the clients get. >> Or we could respond with "What you have is okay, I may send you some >> pushes", by returning an empty result > > That seems better. > That's quite the same except for the order of sending. It's better in case we treat interim pushes exactly the same as normal ones.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
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). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
Dave Cridland wrote: >> 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. > > We decided that each roster push was in and of itself atomic, so the > "transaction" you're referring to doesn't exist - each roster push can > be effectively treated as an atomic commit point in and of itself. I still think it exists, let me explain my point of view more precisely. Here is set of versions: Client knowns 305, current version is 308. The server will send 307, 308 and the notification that the latest version is 308. Let's assume that connection was broken and client got 307 but not 308, client does not know version 307 at the moment, as it *does* *not* know that bill@ has subscription="to". That's why I name the set of stanzas a "transaction" and that's why I'm against of processing interim roster pushes until client has received all pushes. Let me extend the example and show how things may get wrong if client behaves in another way. While client was reconnecting some more roster version bumps occured, let them include some "reverting" change: Now the difference between 307 and 310 includes nurse@ but does not include b...@. So client will not know that bill@ has subscription="to" and will continue to assume that bill@ has subscription="none" (as it was in version 305). XEP-0237 does not state that server should send "final state of all touched roster items", it should send "the final result of all changes applied" and the result may be understood as the difference. Am I mistaken somewhere? Moreover, after constructing this example I don't think that caching parts of transaction is a good idea. Caching will introduce several corner cases. By the way, I added nurse@ to this example to avoid sending empty difference between two different versions of the roster as XEP suggests no way to do that. I'm not completely sure that "unchanged" reply is the best way to handle the situation. -- WBRBW, Leonid Evdokimov signature.asc Description: OpenPGP digital signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/17/09 9:07 AM, Dave Cridland wrote: > On Fri Apr 17 16:05:06 2009, Jiří Zárevúcký wrote: >> 2009/4/17 Dave Cridland : >> >> > While you're looking at this, what's your opinion on the empty >> roster case? >> > (That is, when a roster becomes empty). >> > >> > It's an odd edge case, but I'm not sure the protocol handles this >> usefully. >> > >> >> That's really tricky. And surely can't stay that way, since client >> wouldn't know, how to interpret it in some cases. >> >> I think it could be solved by sending interim pushes _first_, then an >> empty IQ result to mark interim pushes were all sent. >> What do you think? We can't send an IQ-result that's unrelated to any IQ-set or IQ-get. > Or we could respond with "What you have is okay, I may send you some > pushes", by returning an empty result That seems better. > - we've established there's no > need to treat these pushes any differently to normal ones, after all. That principle is key, here. > This then means that an empty roster is different to an empty result, > and means fewer octets for the optimal case. Aha, so you are suggesting that an empty roster is this: Whereas an indication that you are up to date (aside from possibly some roster pushes) is this: Correct? /me ponders Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Dave Cridland : > On Fri Apr 17 16:05:06 2009, Jiří Zárevúcký wrote: >> >> 2009/4/17 Dave Cridland : >> > On Fri Apr 17 15:06:36 2009, Jiří Zárevúcký wrote: >> >> >> >> 2009/4/17 Peter Saint-Andre : >> >> > >> >> > Jiří, it's better to raise issues than to ignore them. Sometimes we >> >> > conclude that the issue isn't very serious, but often we don't know >> >> > that >> >> > until we discuss it for a while. So keep posting! >> >> > >> >> >> >> Sure, I will. >> >> 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. >> > >> > While you're looking at this, what's your opinion on the empty roster >> > case? >> > (That is, when a roster becomes empty). >> > >> > It's an odd edge case, but I'm not sure the protocol handles this >> > usefully. >> > >> >> That's really tricky. And surely can't stay that way, since client >> wouldn't know, how to interpret it in some cases. >> >> I think it could be solved by sending interim pushes _first_, then an >> empty IQ result to mark interim pushes were all sent. >> What do you think? > > Or we could respond with "What you have is okay, I may send you some > pushes", by returning an empty result - we've established there's no need to > treat these pushes any differently to normal ones, after all. > > This then means that an empty roster is different to an empty result, and > means fewer octets for the optimal case. > I completely agree. I think that knowing, how many versions are to be expected on startup, doesn't matter for any implementation.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On Fri Apr 17 16:05:06 2009, Jiří Zárevúcký wrote: 2009/4/17 Dave Cridland : > On Fri Apr 17 15:06:36 2009, Jiří Zárevúcký wrote: >> >> 2009/4/17 Peter Saint-Andre : >> > >> > Jiří, it's better to raise issues than to ignore them. Sometimes we >> > conclude that the issue isn't very serious, but often we don't know that >> > until we discuss it for a while. So keep posting! >> > >> >> Sure, I will. >> 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. > > While you're looking at this, what's your opinion on the empty roster case? > (That is, when a roster becomes empty). > > It's an odd edge case, but I'm not sure the protocol handles this usefully. > That's really tricky. And surely can't stay that way, since client wouldn't know, how to interpret it in some cases. I think it could be solved by sending interim pushes _first_, then an empty IQ result to mark interim pushes were all sent. What do you think? Or we could respond with "What you have is okay, I may send you some pushes", by returning an empty result - we've established there's no need to treat these pushes any differently to normal ones, after all. This then means that an empty roster is different to an empty result, and means fewer octets for the optimal case. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Dave Cridland : > On Fri Apr 17 15:06:36 2009, Jiří Zárevúcký wrote: >> >> 2009/4/17 Peter Saint-Andre : >> > >> > Jiří, it's better to raise issues than to ignore them. Sometimes we >> > conclude that the issue isn't very serious, but often we don't know that >> > until we discuss it for a while. So keep posting! >> > >> >> Sure, I will. >> 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. > > While you're looking at this, what's your opinion on the empty roster case? > (That is, when a roster becomes empty). > > It's an odd edge case, but I'm not sure the protocol handles this usefully. > That's really tricky. And surely can't stay that way, since client wouldn't know, how to interpret it in some cases. I think it could be solved by sending interim pushes _first_, then an empty IQ result to mark interim pushes were all sent. What do you think?
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On Fri Apr 17 15:06:36 2009, Jiří Zárevúcký wrote: 2009/4/17 Peter Saint-Andre : > > Jiří, it's better to raise issues than to ignore them. Sometimes we > conclude that the issue isn't very serious, but often we don't know that > until we discuss it for a while. So keep posting! > Sure, I will. 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. While you're looking at this, what's your opinion on the empty roster case? (That is, when a roster becomes empty). It's an odd edge case, but I'm not sure the protocol handles this usefully. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On Fri Apr 17 15:18:37 2009, 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. We decided that each roster push was in and of itself atomic, so the "transaction" you're referring to doesn't exist - each roster push can be effectively treated as an atomic commit point in and of itself. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Jiří Zárevúcký : > 2009/4/17 Leonid Evdokimov : >> 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. >> > > Ok, that seems like a retelling of the restriction. What is the reason > for it? The reason I posted was invalid. Do you know of some other way > it could negatively affect the retrieval? > I think you misunderstood the sentence. It forbids any processing at all until the full transaction is finished. You can't cache anything.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Leonid Evdokimov : > 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. > Ok, that seems like a retelling of the restriction. What is the reason for it? The reason I posted was invalid. Do you know of some other way it could negatively affect the retrieval?
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
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. -- WBRBW, Leonid Evdokimov signature.asc Description: OpenPGP digital signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre : > > Jiří, it's better to raise issues than to ignore them. Sometimes we > conclude that the issue isn't very serious, but often we don't know that > until we discuss it for a while. So keep posting! > Sure, I will. 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.
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/16/09 9:23 PM, Jiří Zárevúcký wrote:
> 2009/4/17 Peter Saint-Andre :
>> Ahoj Jirka,
>>
>> On 4/16/09 8:39 PM, Jiří Zárevúcký wrote:
>>> 2009/4/17 Peter Saint-Andre :
I think you're making it too complicated for the typical usage.
Peter
>>> Yeah. You are probably right. These are just nuances that would affect
>>> very little people throughout the whole existence of the protocol, but
>>> given they don't make anything more complex or introduce any
>>> inconveniences for anyone, I think they are worth doing. For all we
>>> know, someone's aggravation over few second longer delay when loading
>>> roster can ultimately lead to World War III... :-D
>> I think that the things you are describing fall into the category of
>> optimizations that a smart client can implement to improve the user
>> experience. But we don't need to describe all that in the spec ("in the
>> unlikely event that you get disconnected after receiving some but not
>> all of the roster pushes, cache what you've received so far but then
>> when you reconnect you can shave a few seconds off the reconnection
>> process by requesting the roster based on the version of the last roster
>> push you cached, not the last full roster update"). That kind of thing
>> is great but IMHO it doesn't really belong in an RFC.
>>
>
> Actually, I described an error scenario that could occur (but probably
> never would, and even if it did, nobody would likely notice) when both
> client and server utilize a specific optimization. :) which is
> probably making half of this thread a truly regrettable waste of your
> time... sorry about that... :)
Jiří, it's better to raise issues than to ignore them. Sometimes we
conclude that the issue isn't very serious, but often we don't know that
until we discuss it for a while. So keep posting!
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On Fri, Apr 17, 2009 at 4:59 AM, Peter Saint-Andre wrote:
> I think that the things you are describing fall into the category of
> optimizations that a smart client can implement to improve the user
> experience. But we don't need to describe all that in the spec ("in the
> unlikely event that you get disconnected after receiving some but not
> all of the roster pushes, cache what you've received so far but then
> when you reconnect you can shave a few seconds off the reconnection
> process by requesting the roster based on the version of the last roster
> push you cached, not the last full roster update"). That kind of thing
> is great but IMHO it doesn't really belong in an RFC.
+1
In fact in our implementation based on the current xep we haven't seen
any real issue that can't be dealt with good heuristics
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre :
> Ahoj Jirka,
>
> On 4/16/09 8:39 PM, Jiří Zárevúcký wrote:
>> 2009/4/17 Peter Saint-Andre :
>>> I think you're making it too complicated for the typical usage.
>>>
>>> Peter
>>>
>>
>> Yeah. You are probably right. These are just nuances that would affect
>> very little people throughout the whole existence of the protocol, but
>> given they don't make anything more complex or introduce any
>> inconveniences for anyone, I think they are worth doing. For all we
>> know, someone's aggravation over few second longer delay when loading
>> roster can ultimately lead to World War III... :-D
>
> I think that the things you are describing fall into the category of
> optimizations that a smart client can implement to improve the user
> experience. But we don't need to describe all that in the spec ("in the
> unlikely event that you get disconnected after receiving some but not
> all of the roster pushes, cache what you've received so far but then
> when you reconnect you can shave a few seconds off the reconnection
> process by requesting the roster based on the version of the last roster
> push you cached, not the last full roster update"). That kind of thing
> is great but IMHO it doesn't really belong in an RFC.
>
Actually, I described an error scenario that could occur (but probably
never would, and even if it did, nobody would likely notice) when both
client and server utilize a specific optimization. :) which is
probably making half of this thread a truly regrettable waste of your
time... sorry about that... :)
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
Ahoj Jirka,
On 4/16/09 8:39 PM, Jiří Zárevúcký wrote:
> 2009/4/17 Peter Saint-Andre :
>> I think you're making it too complicated for the typical usage.
>>
>> Peter
>>
>
> Yeah. You are probably right. These are just nuances that would affect
> very little people throughout the whole existence of the protocol, but
> given they don't make anything more complex or introduce any
> inconveniences for anyone, I think they are worth doing. For all we
> know, someone's aggravation over few second longer delay when loading
> roster can ultimately lead to World War III... :-D
I think that the things you are describing fall into the category of
optimizations that a smart client can implement to improve the user
experience. But we don't need to describe all that in the spec ("in the
unlikely event that you get disconnected after receiving some but not
all of the roster pushes, cache what you've received so far but then
when you reconnect you can shave a few seconds off the reconnection
process by requesting the roster based on the version of the last roster
push you cached, not the last full roster update"). That kind of thing
is great but IMHO it doesn't really belong in an RFC.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
2009/4/17 Peter Saint-Andre : > I think you're making it too complicated for the typical usage. > > Peter > Yeah. You are probably right. These are just nuances that would affect very little people throughout the whole existence of the protocol, but given they don't make anything more complex or introduce any inconveniences for anyone, I think they are worth doing. For all we know, someone's aggravation over few second longer delay when loading roster can ultimately lead to World War III... :-D
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/14/09 12:44 PM, Jiří Zárevúcký wrote: >> You are raising the scenario of the stream dying right after the server >> sends 303. I'm saying that client 1 MUST NOT consider itself to be up to >> date when it receives 303, because the server has already told it that >> the latest version is 305. Therefore, when the client reconnects it MUST >> behave as if it never received the roster push for version 303 and >> instead send the exact same roster get it sent when it came back online >> (i.e., 299). >> > > Client does not consider itself up-to-date but it would retrieve a > complete state if it starts retrieving again from that particular > point. So it could save the interim pushes as they arrive (if we > disregard the last change to the spec, which was based on wrong > assumptions). You mean this? "The client MUST NOT process any of the interim roster pushes until it has processed all of them (this helps to prevent partial processing if the client loses its connection to the server before it has received all of the interim roster pushes)." > That could make a huge difference if the client is on very low > bandwidth, or expensive connection based on transfered data (which for > example GPRS on mobile phones). I'm not convinced of this. How often do people have a lot of new contacts in their roster? I have 2200 contacts, but even I don't always have a roster change waiting for me when I log in. Usually I have one or two subscription requests to process, but not a roster push. What is the likelihood that I will lose connectivity after the first roster push? And can't I just request the the same state I started with? I think you're making it too complicated for the typical usage. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/14/09 12:44 PM, Jiří Zárevúcký wrote: >> You are raising the scenario of the stream dying right after the server >> sends 303. I'm saying that client 1 MUST NOT consider itself to be up to >> date when it receives 303, because the server has already told it that >> the latest version is 305. Therefore, when the client reconnects it MUST >> behave as if it never received the roster push for version 303 and >> instead send the exact same roster get it sent when it came back online >> (i.e., 299). >> > > Client does not consider itself up-to-date but it would retrieve a > complete state if it starts retrieving again from that particular > point. So it could save the interim pushes as they arrive (if we > disregard the last change to the spec, which was based on wrong > assumptions). > That could make a huge difference if the client is on very low > bandwidth, or expensive connection based on transfered data (which for > example GPRS on mobile phones). Aha, I see what you are saying. That's possible. I'll need to think about it some more... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
> > You are raising the scenario of the stream dying right after the server > sends 303. I'm saying that client 1 MUST NOT consider itself to be up to > date when it receives 303, because the server has already told it that > the latest version is 305. Therefore, when the client reconnects it MUST > behave as if it never received the roster push for version 303 and > instead send the exact same roster get it sent when it came back online > (i.e., 299). > Client does not consider itself up-to-date but it would retrieve a complete state if it starts retrieving again from that particular point. So it could save the interim pushes as they arrive (if we disregard the last change to the spec, which was based on wrong assumptions). That could make a huge difference if the client is on very low bandwidth, or expensive connection based on transfered data (which for example GPRS on mobile phones).
[Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
resend... Original Message Subject: Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning) Date: Tue, 14 Apr 2009 09:15:47 -0600 From: Peter Saint-Andre To: XMPP Standards On 4/14/09 3:06 AM, Jiří Zárevúcký wrote: > But I realized there is a rare scenario where it could really cause problem. > > > > > > > > > > > > > > > > > > > > > > > > > > Client knows 300. The roster would send 303 first, and 305 second. If > connection failed after sending 303, client would next request 303+, > but never received 302 in the first place. There seems to be some confusion about how roster versioning works. Perhaps the spec needs to describe this all in a lot more detail. However, I'll do that here first. Let's say you have two clients, 1 and 2. 1 is up to date as of ver='299' and then goes offline. 2 stays online and completes some roster management tasks. Then 1 comes back online. 1: S: 1: [first roster update from client 2, with Set and Push] 2: S: [second roster update from client 2, with Set and Push] 2: S: [third roster update from client 2, with Set and Push] 2: S: [Alice approves subscription request from user] S: [client 2 approves subscription request from Bob] S: [Bob sends unsubscribe] S: Now the user comes back online with client 1. 1: So the server needs to send what's changed to client 1. It does this, not by sending 300, 301, 302, 303, 304, and 305, but by sending the effective difference between 299 and 305. First it tells client 1 that there are changes: S: That means "the latest version is no longer 299 but I'm going to send you the changes as roster pushes -- when you receive a push numbered 305 then you know you're up to date". Now the server sends two roster pushes: one related to Alice (303) and one related to Bob (305): S: S: Therefore client 1 knows that it's up to date, and it has received the most recent information about each roster item that was changed while it was offline. You are raising the scenario of the stream dying right after the server sends 303. I'm saying that client 1 MUST NOT consider itself to be up to date when it receives 303, because the server has already told it that the latest version is 305. Therefore, when the client reconnects it MUST behave as if it never received the roster push for version 303 and instead send the exact same roster get it sent when it came back online (i.e., 299). > Now (only) in case the server checks the last state client should > know, it will find out it doesn't need to send the push since there is > the same state as in 302. Client wouldn't receive bob's name until > next change. > > That is easily fixed by disallowing servers such checks. Sure. Perhaps we need an implementation note for servers, which says: "basically, you need to keep a record of each roster item that has changed since the last roster get(s) for this account, but you don't need to keep a record of each change, only the last state related to each changed item". Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
