http://bugs.freedesktop.org/show_bug.cgi?id=18291
Summary: TpConnectionManager API is avoidably cumbersome
Product: Telepathy
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: telepathy-glib
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
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.
Contrast:
- 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.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
