Bug 25288

Summary:	add ChannelDispatcher.CouldHandleChannel
Product:	Telepathy	Reporter:	Danielle Madeley <danielle>
Component:	tp-spec	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED DUPLICATE	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:	needs-impl
i915 platform:		i915 features:

Description Danielle Madeley 2009-11-25 14:43:29 UTC

This has grown out of https://bugzilla.gnome.org/show_bug.cgi?id=589224

If you're adding API anyway, you might as well ask the question you actually
want to ask, rather than starting a speculative request and then cancelling it.
Something like this:

ChannelDispatcher.CouldHandleChannel(a{sv}: Properties) -> b [or as?]
    Check whether a requested channel whose immutable properties were
    Properties could be handled. Return TRUE if so.

    [Or: return the expected ChannelDispatchOperation.PossibleHandlers
    property for such a channel.]

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

Comment 1 Danielle Madeley 2009-11-25 16:24:49 UTC

Decided to call this method GetPossibleHandlers.

Spec addition: http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/get-possible-handlers

Comment 2 Danielle Madeley 2009-11-25 16:53:47 UTC

To clarify, my implementation returns an 'as' of well-known names like ChannelDispatchOperation.PossibleHandlers

Comment 3 Simon McVittie 2010-04-09 04:18:13 UTC

tp:added should contain (or end with) UNRELEASED, so that our release procedure catches it and replaces it with the correct version - it would be incorrect to claim that this method was added in 0.18.0.1 when it isn't even in 0.19.3.

I like the spec proposal, but to be merged, this needs a prototype implementation in a Mission Control branch. Wiring up the existing code to a G_GNUC_UNUSED function with the same signature that the D-Bus method would have would be a sufficient prototype, I think.

Comment 4 Guillaume Desmottes 2010-06-18 07:20:13 UTC

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.

Comment 5 Simon McVittie 2010-06-18 08:00:17 UTC

(In reply to comment #4)
> 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.

That's an interesting point. Care to design a spec/implementation for that?

Comment 6 Simon McVittie 2010-06-18 08:07:21 UTC

Thinking about it, one easy way to design this would be to assume the available clients will change infrequently, and use this sort of pattern:

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 7 Simon McVittie 2010-06-28 09:57:08 UTC

(In reply to comment #6)
> Thinking about it, one easy way to design this would be to assume the available
> clients will change infrequently, and use this sort of pattern:
> 
> interface o.fd.T.ChannelDispatcher.Interface.PossibleHandlers
> 
>     method GetPossibleHandlers(a{sv}) -> as
...
>     signal HandlersChanged()

This is, in fact, Bug #19589.

*** This bug has been marked as a duplicate of bug 19589 ***

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.