[Bug 29417] Add API to get a TpAccount from a TpContact and/or TpConnection

[bugzilla-daemon at freedesktop.org]

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

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-06 03:41:40 PDT ---
We've discussed this on IRC and not really come to a conclusion; there are some
problems with a naive approach, like reference-counting cycles between the
account and connection.

In Handlers and similar channel-oriented things, we shouldn't generally need
this, because there'll usually be an object (e.g. an Empathy chat tab) that
knows its own account, connection and channel.

The difficult case is when you have a contact but you're not account- or
channel-specific, like the Empathy contact list owning TpContact objects, and
wanting to know which account to pass to ChannelDispatcher.EnsureChannel when
you click on a contact. The contact list is account-agnostic, although I think
we can safely assume it has a ref to the TpAccountManager.

10:48 < Zdra> smcv, the use case is: "I have a TpContact and I want to request 
              a channel for it", the dispatcher needs the account
10:48 < smcv> devil's advocate: isn't that just an artefact of us not having 
              metacontacts yet?

Some possibilities:

What Zdra proposed in Comment #0
================================

10:50 < smcv> the correct form of "they each ref the other" would be that the 
              Connection releases its ref when invalidated
10:50 < smcv> or soemthing

We could have:

TpAccount refs TpConnection until the TpConnection is invalidated. TpConnection
refs TpAccount.

10:43 < smcv> I don't think adding a property whose value might be a lie is the 
              right solution
10:43 < danni> smcv: well it's either real or NULL
10:43 < danni> and we can define the semantics by which it will be real or NULL
10:43 < smcv> right, but the NULL case means "either it doesn't belong to an 
              account or I have no idea"
...
10:44 < danni> smcv: if we define the semantics, the programmer will know 
               whether she expects it to be null or not
...
10:55 < smcv> the relationship isn't strictly 1:1, which is an extra wart
10:56 < smcv> if you keep hold of refs to a dead TpConnection, then they still 
              belong to the same Account you first thought of, but are not the 
              *current* Connection for that Account

Global lookup table
===================

Rejected:

10:43 < Zdra> smcv, danni: what about TpAccount 
              *tp_account_lookup_for_connection(TpConnection){return 
              g_hash_table_lookup (global_conn_to_acc_table, connection);}
10:44 < Zdra> hm, nevermind, that's just the same has having prop on the conn

Connection knows the *object path of* its Account
=================================================

This has the same issues as Comment #0 in terms of not always having the
necessary information, but unlike Comment #0, it doesn't have cyclic
references.

10:57 < smcv> one way to not have the ref cycle would be for the TpConnection 
              to know its own Account *by object path*
...
11:04 < smcv> you can emulate tp_am_ensure with tp_account_ensure 
              (tp_am_ensure_account (am, path), ...) in any case

Ability to look up the account for a connection in the TpAM
===========================================================

telepathy-qt4 has something quite similar to this.

10:32 < wjt> add a method to the AM to get the A for a Conn
10:33 < wjt> see also, the Tp::AccountSet API in tp-qt4  
10:36 < Zdra> smcv, do you prefer something like this? 
              tp_account_manager_get_account_for_connection(connection){for 
              (all accounts) if (account.connection == connection) return 
              account;} ?  
10:36 < danni> the problem is if you have multiple account proxies/connection 
               proxies, it gets messy
10:36 < danni> which one do you mean
10:37 < smcv> danni: the one the AM has in 
              tp_account_manager_get_valid_accounts()
10:37 < smcv> danni: for bonus penguin points match by object path instead of 
              by identity :-)
...
10:40 < danni> smcv: also, now you have to prepare more stuff, which you really 
               don't care about

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