[Bug 21787] Connection.Interface.ContactLists

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=21787

--- Comment #43 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-07-22 04:21:24 PDT ---
(In reply to comment #42)
> Splitting apart ContactsChanged and ContactsRemoved might make the API more
> understandable. In all of telepathy-glib and Gabble, there's only one call to
> tp_base_contact_list_contacts_changed where both parameters are non-NULL, and
> in practice I don't think that will ever happen

It seems I spoke too soon. When I made the contactlist example a bit more
realistic, I realised that if you have this behaviour (which is what it now
emulates):

- a persistent protocol-level roster, like in XMPP, containing (say) [Alice,
Bob]
- a transient list of people who want to add you, containing [Bob, Chris]
- GetContactListAttributes returns the union of the two lists
- protocol-level operations can act on multiple contacts (unlike XMPP)

then rejecting a subscription request from someone not on your protocol-level
roster (Chris, but not Bob, here) causes them to be "removed" (they were never
really stored in the first place). This means that Unpublish([Alice, Bob,
Chris]) would naturally result in ContactsChanged(Changed={Alice: (...), Bob:
(...)}, Removed=[Chris]). The example now behaves like this.

Of course, we could still split it into two signals if simplicity of each
signal is considered more important than simplicity of the interface (i.e.
fewer signals).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.