[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 #26 from Jonny Lamb <jonny.lamb at collabora.co.uk>  2009-09-26 04:16:53 PST ---
(In reply to comment #19)
> 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.)

Okay, I made _set_connection stop listening to invalidated and listen for a "/"
connection object path.

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

I have made _get_connection lazily create a TpConnection when called.

> In the short term, tp_account_ensure_connection seems sufficient.

Not if we don't have the connection object path, which is why I kept
_get_connection.

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

Why remove it? If it is defined as having the same guarantees as the connection
getter which is staying around, there is no point removing it, or do you want
the option to have a :connection property later on with different semantics
from _get_connection?


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