Hi, 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.
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. Also consider that the server is implemented to send the complete roster and not the interim roster pushes. Regards, Sachin Khandelwal On Thursday 09 April 2009 18:09:57 Matthew Wild wrote: > On Thu, Apr 9, 2009 at 7:54 AM, Sachin Khandelwal <[email protected]> wrote: > > Hi, > > > > Addition of this feature is highly appreciated. > > There is a small issue which will occur in rare scenario : > > > > In sec 2.4, "Example 4. Roster result with no items" > > > > <iq from='[email protected]' id='r1' to='[email protected]/home' > > type='result'> > > <query xmlns='jabber:iq:roster' ver='317'> > > </iq> > > > > The above example is for the case when server will send the individual > > roster pushes for the changes rather then sending the complete roster. > > But the server will return the same response (while returning complete > > roster) when user has deleted all the rosteritems present previous > > version (say 316). > > <this-space-intentionally-left-blank/> > > I'm not sure that I see this as a problem. If a client requests r317 > then it already knows that the contacts have been deleted, there will > be no roster pushes, and there needn't be any. If it requests 316 then > it can be notified of the deletion of the single contact and then > upgraded to 317. > > Am I missing something? > > Matthew.
