[Bug 26205] High-level API for ContactLists

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2011-02-22 02:36:29 PST ---
(In reply to comment #1)
> TpConnection::contact-list-changed (GList *added, GList *removed);

If we fire this signal as soon as we get the ContactsChangedWithID, most
clients (if not all) will have to call tp_connection_upgrade_contacts() on the
newly added contacts as they can't do much whitout having the contacts
features. That' a bit of a shame for an high level API whose goal is to make
client's life easier.

One solution would be to queue all D-Bus signals (to keep ordering) and not
fire the GObject ones until at set of features have been prepared. This set of
feature could be either be set implicitely or just be the intersection of the
ones passed to tp_connection_contact_list_get_contacts_async().

Actually I'm wondering if we shouldn't go for an approach similar to tp-qt4:
having a contact-factory (similar to our channel-factory) doing the contact
preparation. We could maybe even have a TpContactList object created from the
TpConnection to which we pass the contact factory we want to use.
That would avoid the case where a plugin wants to prepare some extra feature
and so delay all the other components to get contacts (assuming they share the
same proxy objects).

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