[Bug 26205] High-level API for ContactLists

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jun 1 17:47:14 CEST 2011


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

--- Comment #8 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-06-01 08:47:13 PDT ---
(In reply to comment #7)
> 1) a feature on TpConnection telling to create TpContact for all known
> contacts, with a method to get them all, and a signal telling those
> added/removed.

s/all known contacts/all contacts on the contact list/

(yes, there is a distinction - consider blocked contacts)

This shouldn't imply "wait til the contact list is ready" because that might
never terminate (consider MSN when the contact list server has fallen over -
you can still talk to people, and having everything wait for this desired
feature to be ready wouldn't be beneficial.)

If getting the contact list has failed, there should be an accessor for the
error we saw last time we tried?

The state property added by your branch should probably delay moving to
Succeeded until we have actually downloaded the complete list of contacts, if
we're trying to do that?

> 2) a way to define on TpConnection the features we want to be prepared on all
> known contacts before exposing them

"features we want to be prepared on new contacts before signalling them"?

Or we could just say "you will get at least subscription states, everything
else you have to wait for".

> 3) tp_connection_*_async(TpConnection *, array<TpContact>) and
> tp_contact_*_async() for all those methods:
> 
> RequestSubscription
> AuthorizePublication
> RemoveContacts
> Unsubscribe
> Unpublish

I think this is more important than (2).

While you're writing boilerplate you might also want block, unblock and
block-and-report-abuse (the Blocking interface).

Regarding your branch:

> + "ContactList can change", "Whether the contact list can change",

No, it might be able to change even though *we* can't change it (consider
Facebook).

> + * TP_CONNECTION_FEATURE_CONTACT_LIST:

I'm a bit wary about using this feature name for something that isn't your
stage (1) above. If I activate the "contact list" feature, surely I should have
a list of contacts?

You could either rename this to CONTACT_LIST_PROPERTIES, or decide that it will
imply "contact list will be present as a list of TpContact, if the CM-side
state allows it" (i.e. combine it with (1)).

-- 
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.



More information about the telepathy-bugs mailing list