[Bug 24061] TpAccount, TpAccountManager: add convenience API similar to libempathy's

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24061





--- Comment #19 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-09-25 12:38:26 PST ---
Further to TpAccountManager::new-connection: it appears that TpAccount always
creates a Connection whenever it has a non-empty object path.

I think that's a bad idea, because of the "sugar-presence-service
anti-pattern", by which I mean:

* client binding for container (Sugar's PresenceService, originally)
* objects in the container (Activity and Buddy, originally) that "most" clients
of the container don't care about "most" instances of
* when a new object appears, D-Bus traffic is needed to set up a proxy for it
* the proxy is emitted in a signal
* nobody actually cares, so the signal is ignored
* the proxy is unreffed and destroyed, and the D-Bus traffic was a waste of
time
* for bonus points (as seen in Sugar), many applications have a reason to watch
the container, so you get a thundering herd of applications all doing
unnecessary work simultaneously

It sounds silly, but this was a practical performance problem on OLPC/Sugar -
worse, we couldn't even fix it, because it was an API guarantee.

For an easy example of something that watches an Account but doesn't care about
its Connection, consider an account setup UI. A more subtle example is a
handler for channels, which only cares about the Connection for each Channel
that it's handling.

So, I don't think _tp_account_set_connection should do what it currently does
(set up a TpConnection and watch for it to be ready or invalidated). The
Account D-Bus API was specifically designed so that this wouldn't be necessary
for basic use of an account: when the connection drops, you get something like
AccountPropertiesChanged({Connection: "/", ConnectionStatus: DISCONNECTED,
ConnectionStatusReason: OUT_OF_CHEESE}). (This is also why the Account proxies
the current presence through itself.)

Currently, they might arrive in different signals because MC's internals are
weird (I should probably file a bug about that). The safest thing to do would
be to just remember the reason, and use it when connection status DISCONNECTED
or Connection "/" arrives (connection statuses CONNECTING and CONNECTED are
always for reason REQUESTED in practice).

For those clients that *do* care about the TpConnection,
tp_account_get_connection could create one lazily (if the object path is not
"/"), or the guarantee to have a TpConnection (or a ready TpConnection, if you
prefer) could be a Feature.

In the short term, tp_account_ensure_connection seems sufficient.

Similarly, we should consider removing TpAccount's connection property,
temporarily or permanently.


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