On 4/9/09 9:16 AM, Matthew Wild wrote: > Now I'm being bad and replying to 2 mails at once, sorry :) > > On Thu, Apr 9, 2009 at 3:53 PM, Peter Saint-Andre <stpe...@stpeter.im> wrote: >> On 4/9/09 7:57 AM, Sachin Khandelwal wrote: >>> Let me elaborate this : >>> Consider user 'xmpp1' uses two clients to login (say one from home and one >>> from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the >>> roster >>> version is 316. Both the office client and home client are upgraded to >>> version >>> 316. Now from office client user deletes the contact ( home client is not >>> logged >>> in that time). Now when xmpp1 login from home client the response of roster >>> retrieval will be same as Example 4. >>> > > No, xmpp1 at home will request the version it knows about... 316. The > server will reply with an empty 317, and also send a roster pushe for > the removal of the 316 contact. No?
I think Sachin's point is that if the server is sending complete roster (not subsequent roster pushes), then the client won't know if the empty <query/> means (1) here is the complete roster but there's nothing in it (2) no changes. But I think that reasoning is not quite right. 1. xmpp1 requests 316 (which had one item in it) 2. server returns 317 with empty query element So xmpp1 knows that the roster has changed. And the change is, there's nothing in the roster. >>> Here my concern was how the client will come to know that the response is >>> actually a zero rosteritem (empty roster) condition and not that "the roster >>> changes will be sent later as interim roster pushes" as mentioned in sec >>> 2.4. >>> > > I don't think it has to know (though see above, since it I believe it > *will* know). It simply presents the roster it knows about, until it > receives further notice from the server (which will be the roster > pushes). > >>> Also consider that the server is implemented to send the complete roster and >>> not the interim roster pushes. >> That's an interesting edge case. I'm not yet sure how to solve it. >> You're right that with roster versioning an empty <query/> element now >> can mean two different things. This requires further thought. >> > > I wouldn't be opposed to making an empty roster explicit, or > preferably a non-empty roster explicit, e.g. some way to say "updates > are coming" or better "X updates are coming". I suppose there would be no harm in defining a flag in the roster result that says "expect roster pushes with the diff". I'm not yet sure that's needed, though. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
