The use case here is telling whether a handle you see in a PresenceUpdate is channel-specific or not.

I think this should be a method on the connection interface:

  GetHandleOwners :: au -> a{u(uo)}

That is, return a map of handle to (owner handle, path the channel is specific to). If an input handle is not channel-specific, the dictionary entry is omitted. If the handle has no known owner, the owner handle is 0.

This works if handles can only be specific to one channel at a time. Simon suggests that a handle might be specific to multiple channels but I forget his rationale and it seems quite bizarre to me. If we do need to support that (I hope we don't), we can have:

  GetHandleOwners :: au -> a{u(uao)}

We can indicate non-channel-specificity by non-inclusion or having the array of channel paths be empty.

With regards to backwards compatibility, do we need to put this in its own interface?

In terms of implementation, I suspect most connection managers will end up iterating over all the chanels they have internally.

I think it would be nice to include this in the Contacts interface, too. Currently the spec says, of the return value of GetContactAttributes:

> Each contact's attributes will always include at least the identifier that would be obtained by inspecting the handle (org.freedesktop.Telepathy.Connection/contact-id).

We probably want /owner (Handle), /owner-id, /owner-channels or so. This is kind of a prerequisite for adding handle owner support to contact helper code in bindings, short of requiring API users to pass the channel to the constructor as well as the handle.

I don't think we need this to be on a separate interface for backwards compat. — if the method's not implemented on the connection, you just can't figure this out.

(In reply to comment #1)
> Simon
> suggests that a handle might be specific to multiple channels but I forget his
> rationale and it seems quite bizarre to me.

I guess one example is a contact in an XMPP MUC being used for both a text chat and a Muji call?

-- 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-spec/issues/14.