We don't have any API to easily know if a TpContact is channel specific or not. What about adding something like: /** * tp_contact_is_channel_specific: * @self: a #TpContact * * Returns: (transfer none): a #TpChannel if @self is specific to this channel, * %NULL otherwise */ I'm not fan of having a _is_ method returning a non gboolean, but the TpChannel is useful to get the owner if we want to (using tp_channel_group_get_contact_owner()). Also, the documentation of this method would be a bit weird as it will rely on TP_CHANNEL_FEATURE_CONTACTS being prepared on the *channel*...
Note that if CM has recent-enough spec (anything based on tp-glib), TpChannel will ALWAYS create all its TpContact objects. This is because GROUP feature is part of CORE, and new spec gives handle+id so creating contacts is free. CONTACTS feature is to also ensuring those contacts have factory features prepared, which is not free. I would call the new method: gboolean tp_contact_is_channel_specific (TpContact *self, TpChannel **out_channel); And accept out_channel==NULL. That API could also be useful as guard for all tp_contact_request_subscription_async(), tp_connection_request_subscription_async() and all their friends. Adding there g_return_if_fail (!tp_contact_is_channel_specific(contact, NULL)); So this is a +1 from me.
oh, be careful about cyclic referencing! TpChannel already keeps ref on its TpContact, so you'll probably have to keep a weak-ref on the channel from the TpContact.
The big problem is that we don't want to introduce a ref cycle between the TpContact and the TpChannel (the TpChannel currently has a ref on the contact). We have 2 options here: A) The TpContact keeps a weak ref on the TpChannel. I don't like this option because that means that if user drops the ref on the TpChannel we can't give it back to him using this API. That makes a bit pointless and not reliable: an API shouldn't have a different comportement if you dropped so misc ref before. B) The TpContacts keeps a strong ref on the TpChannel and breaks the cycle when the the channel is invalidated. I don't like this approach either because that means TpContact and TpChannel objects will stay alive until the channel is closed. For process like Observer or Approvers who just want to do a few things with the channel and then forget about it that would result in a massive waste of memory. So I think I'm going to defer this for now.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-glib/issues/76.
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.