Bug 18291 - TpConnectionManager API is avoidably cumbersome
Summary: TpConnectionManager API is avoidably cumbersome
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-glib (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
Depends on:
Reported: 2008-10-29 05:54 UTC by Will Thompson
Modified: 2009-02-16 10:01 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Will Thompson 2008-10-29 05:54:11 UTC
There are two main use cases Daf and I can think of for TpConnectionManager:

* Listing all protocols supported by all CMs (the single CM case is similar); you would want to do this in Empathy's account dialog, for instance.

* Calling RequestConnection and connecting to NewConnections; the AccountManager would want to do this.

Currently, the second case is easy (you create a TpCM, connect to the NewConnections DBus signal, call the method, and ignore the got-info GLib signals that will be emitted at various hard-to-predict times), but the first is hard (even if #18207 is fixed):

- call tp_list_connection_managers
- when the callback fires, for each CM, connect to got-info
- when got-info fires:
  > if it's FILE, we're done for this CM.
  > if it's NONE:
    * call tp_cm_activate; the object is useless to us without the protocol info
    * when got-info fires again for this CM:
      # if it's LIVE, we're done for this CM
      # if it's NONE, this CM is a writeoff.
- when we've finished or written off all CMs: actually do what we hoped to do.


- call tp_list_connection_manager_and_introspect_them
- when the callback fires, we're ready to go.

In fact the got-info signal is not very useful at all. The only case when we might want such a signal is:

* haze grew a new protocol, and either restarted or emitted a magic new signal to say so
* we're still showing the Accounts dialog
* we want to update it on the fly.
Comment 1 Alberto Mardegan 2009-02-04 08:39:54 UTC
I think this issue should be solved with an API similar to the _call_when_ready() of TpChannel and TpConnection (as a plus, a weak object parameter would be great).

Having something like tp_list_connection_manager_and_introspect_them() could be good too, but mission-control wouldn't use that in any case (because it is only interested in managers which have some defined accounts).

BTW, the current implementation has a bug: if the .manager file is missing, the "got-info" signal will never be emitted.
Comment 2 Simon McVittie 2009-02-04 11:18:41 UTC
Let's use this bug for the long-term improvement of the API / deprecation of got-info (a concept of "ready" like mardy suggests, probably) and #18207 for short-term fixes to deficiencies in the got-info API.
Comment 3 Simon McVittie 2009-02-16 10:01:44 UTC
Fixed in 0.7.26

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.