On Mon, Jul 13, 2009 at 11:07 PM, Brian Cully<[email protected]> wrote: > I am using it in-house with an ad-hoc command interface, and it works > passably. I'm not sure about the points raised here. Regarding lack of > feedback, this might be considered a feature. My understanding of roster > push is that it merely advises the client to make changes to its roster and > is only concerned with the client having accepted the changes (even if it > didn't employ them). If a client decides not to take a change a future > request for a roster push probably shouldn't push out that change again (the > client already reviewed it and said, "no").
Indeed this is the problem we have in absence of feedback: we don't know if the client reject it or it simply didn't process it, and therefore we can't resend additions. The result we observed is that after a while the roster then to be de-synchronized > As for re-synchronizing the roster, as I recall the spec there's no > way to synchronize the roster either. Hence the ad-hoc command interface, > which can be easily extended to do a full push again, if necessary. This is one option we have, however there is no easy way to detect deletions with the present specs (the client can't keep track of who added the contacts, so missing contacts in the resend can't be dedected > That being said, I'm not the biggest fan of XEP-0144, and would be > keen to see any proposed changes although I lack any of my own at this time. Briedly waht we have in mind: - for the first issue we plan to add an id to the addition <iq type="set"> <x xmlns='http://jabber.org/protocol/rosterx' xid='1234'> <action type="add"/> <!-- items --> </x> </iq> The client therefore sends a result when it receives the stanza, as it happens now. Then after the user has processed the changes it sends back <iq/> containing the accepted items <iq type="set"> <x xmlns='http://jabber.org/protocol/rosterx' xid='1234'> <result/> <!-- items --> </accepted> </x> </iq> - for the second issue we would like to send an <iq/> of type get, specifying a "query" asking for all the contacts of a given group or domain, so that we can compare the result with the contacts we have in the roster and detect deletions too; as you say this can be done with an ad hoc command too, in that case I'd like to write an example in the xep in order to document the practice. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [email protected]
