Bug 19589 - Need a way for clients to know what kinds of channel can be handled.
Summary: Need a way for clients to know what kinds of channel can be handled.
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
: 25288 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-15 09:16 UTC by Will Thompson
Modified: 2019-12-03 20:17 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Will Thompson 2009-01-15 09:16:54 UTC
Currently, a client can look at a Connection's RequestableChannelClasses property to figure out what kinds of channels it can request. But this is not necessarily useful:

* A CM might support channels with THT: Room, but that's not to say that there's a client installed that can handle them. So a contact list UI might look at RCC, see that rooms are available, and have a bunch of room-related UI which is actually useless because any channels that get created will be terminated with extreme prejudice by the dispatcher.
* A client can see that Gabble supports 1-1 stream tubes, but that doesn't help it figure out what services to offer when you right-click a contact. It should be able to have a "Play Tic-Tac-Tube" option.

This information is already present in the form of the union of all activatable and running clients' HandlerChannelFilter properties, applied to the CM's requestable channel classes. So maybe extra spec is unnecessary.

There's also a localization issue here: every contact list needs to know what the human-readable description of service=tictactube is.
Comment 1 Simon McVittie 2009-03-20 11:27:28 UTC
We could add this as a mutable, signallable property on the ChannelDispatcher?
Comment 2 Simon McVittie 2010-06-28 09:57:08 UTC
*** Bug 25288 has been marked as a duplicate of this bug. ***
Comment 3 Simon McVittie 2010-06-28 10:04:14 UTC
Bug #25288 has two similar proposals:

ChannelDispatcher.GetPossibleHandlers(a{sv}: Properties) -> as
    Check whether a requested channel whose immutable properties were
    Properties could be handled. If so, return the expected
    ChannelDispatchOperation.PossibleHandlers property for such a channel;
    if not, return an empty list.

    | This is appropriate for UIs to check whether a suitable client for
    | a request is installed; for instance, Empathy could use it.

    The channel dispatcher SHOULD assume that { Requested => TRUE } is
    in the Properties, even if it's not specifically given.

    | This matters if you have a client that only handles outgoing 
    | channels, like a Vino "share my desktop" request.

and

interface o.fd.T.ChannelDispatcher.Interface.PossibleHandlers

    method GetPossibleHandlers(a{sv}) -> as

        [... documented as before ...]

        Clients MAY cache the result of this method (or more practically,
        decisions based on the result of this method), and use HandlersChanged
        to detect when to update their caches.

        | For instance, the Empathy contact list has a "Share my desktop"
        | menu item, which is visible when a VNC tube handler such as Vino
        | is available.

    signal HandlersChanged()
        Emitted when the set of available handlers has changed. Clients
        that cache the results of GetPossibleHandlers SHOULD call that
        method again.
Comment 4 Simon McVittie 2010-06-28 10:05:04 UTC
Danielle's branch implementing the former proposal from Comment #3:
http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=commitdiff;h=52b75f4d9d1ad6307d3fca523e2aedb8819eb84d

An Empathy bug blocked by this:
https://bugzilla.gnome.org/show_bug.cgi?id=589224
Comment 5 Simon McVittie 2011-05-11 05:40:44 UTC
I'd prefer the version with a change signal, because as Guillaume pointed out on the duplicate bug (which has more discussion):

> Now that Vino is finally a proper channel handler I'd really like to have this
> method.
> Ideally I'd need a change signal as well so I can just cache the result instead
> of making a D-Bus call each time the contact menu is open.

To get the spec beyond a draft someone will need to implement it in MC.

mck182 on #telepathy was interested in using this to detect an audio/video call handler (and so decide whether to allow outgoing audio/video calls) in KDE-Telepathy.
Comment 6 Guillaume Desmottes 2012-02-29 06:00:01 UTC
For the record, this blocks https://bugzilla.gnome.org/show_bug.cgi?id=589224
Comment 7 GitLab Migration User 2019-12-03 20:17:54 UTC
-- 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/20.


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.