[Bug 53818] Allow clients to control their capabilities from being always advertised

[bugzilla-daemon at freedesktop.org]

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

--- Comment #8 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #6)
> "Mission
> Control knows that the Handler has capability X, but also knows that the
> user wants to ignore it, so it doesn't take it into account when selecting
> the PossibleHandlers".

It is technically possible for an Approver to return a Handler that was not
offered to it; Mission Control will try to comply. Should this mechanism make
Mission Control reject attempts to HandleWith(the forbidden Handler)? (I think
it probably should.)

> Does it
> need to contain whole channel classes, or would it be sufficient to act on
> channel types?

Another possibility would be for it to act on Handlers, or to have a hybrid
approach: a list of forbidden Handlers, and a list of forbidden channel types.
If an application wants to support being "partially enabled", it just has to
act as more than one Handler (either several executables, like Empathy and
KDE-Telepathy, or a single executable with several bus names and TpBaseClient
objects).

Here is a straw-man UI which could work with the hybrid approach:

    Enabled features

    [x] Receive voice and video calls      # i.e. Call channels
    [x] Receive incoming file transfers

    Enabled applications

    [x] GNOME Chess                        # Client would need a new map,
    [ ] Quake III Arena                    # { language => translated name },
    [ ] Remote desktop viewer              # and other metadata like Icon
    [x] AbiCollab (AbiWord)
    [x] My.UnfinishedClient

We could have a special case for Call and FT, or just drop the hybrid approach
and list "Empathy voice/video calls" and "Empathy file transfers" in the list
of enabled applications.

Handlers would need a way to say "it doesn't make any sense to disable me",
which would be used by, for instance, Empathy's Auth and Text handlers (Auth is
a behind-the-scenes thing, and in practice IM protocols always assume that
everyone can receive Text).

Would we want to control outgoing (local-user-requested) channels too?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.