[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 #13 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #11)
> > "I want to have call support installed, but have a switch that, when off,
> > makes my Telepathy setup indistinguishable from one that doesn't support
> > calls" is one possible use-case. Is that what you're asking for?
> 
> You got this right. Exactly what I want.

OK, that's useful, and is consistent with the design I had in mind.

> > If that's what you're looking for, do you mean all audio/video calls, or do
> > you mean VoIP (XMPP/SIP/...) specifically, i.e. not counting cellular calls
> > if running on an N9 or something?
> 
> I just meant to have VoIP call advertisement controlled

This is considerably more difficult, because all calls in Telepathy
deliberately look "basically the same".

> > Imagine you have GNOME, Empathy, KDE and KDE-Telepathy installed. Which
> > application provides UI to toggle this feature? Is it desirable for
> > Empathy's call support and KDE-Telepathy's call support to be controlled
> > together, or separately, or do you not mind either way?
> 
> I'd prefer each application to have its own way to control its
> functionality. That's more intutive to the end user.

Apart from the bit about VoIP vs. cellular, that's relatively easy, and can
even be made to work for other "features" than VoIP. I don't think we need
anything as elaborate as matching channel classes: we can just have some way to
enable or disable an entire Client at a time.

For Empathy in its current state (where the Call handler is separate anyway),
we can just have a list of Handlers to ignore, stored by MC and available as a
property on either each Account, the AccountManager or the ChannelDispatcher.
Something like this:

    property IgnoredHandlers: read-only array of string
        A list of Handlers to be ignored. Ignoring a Handler has three
        effects:

        * the ChannelDispatcher behaves as though it doesn't exist
          when calling UpdateCapabilities and the legacy
          method AdvertiseCapabilities;

        * the ChannelDispatcher behaves as though it doesn't exist when
          determining the list of possible handlers;

        * the ChannelDispatcher replies to HandleWith(that Handler) with
          an error.

    method SetIgnoreHandler(string client, boolean ignore) -> nothing
        If ignore is true, add the given client to IgnoredHandlers.
        Otherwise, remove it from IgnoredHandlers.

(Or perhaps we should use a stronger word than "ignore", like "disable" or
"avoid".)

Here is some Python-like pseudocode for how I imagine this would work:

    # disable calls
    >>> cd.SetIgnoreHandler('org.freedesktop.Telepathy.Client.Empathy.Call',
            True)
    # see whether calls are disabled
    >>> cd.Properties.Get('...', 'IgnoredHandlers')
    ['org.freedesktop.Telepathy.Client.Empathy.Call',
     'org.freedesktop.Telepathy.Client.Vinagre']
    # re-enable calls
    >>> cd.SetIgnoreHandler('org.freedesktop.Telepathy.Client.Empathy.Call',
            False)
    >>> cd.Properties.Get('...', 'IgnoredHandlers')
    ['org.freedesktop.Telepathy.Client.Vinagre']

Empathy could have a configuration option:

    [x] enable audio/video calling

whose value corresponds to whether ...Empathy.Call is present in
IgnoredHandlers or not; when clicked, this would call SetIgnoreHandler.

If you have both Empathy and KDE-Telepathy installed, audio/video calling would
only be disabled if both Empathy.Call and KDE-Telepathy's equivalent were in
the IgnoredHandlers list. I think that's what makes sense for the UI you
suggest.

If we want to allow Vinagre to be disabled later, that works too - just add it
to the IgnoredHandlers (as shown in the pseudocode above).

If a particular Client has more than one HandlerChannelFilter, they'll all be
enabled or disabled together; but if you want finer-grained control, a Client
with more than one HandlerChannelFilter can always be replaced by a process
with "more than one head" (multiple Client names, each with their own
HandlerChannelFilter, which can be controlled individually). Older versions of
Empathy worked like this.

Here are some things that might require a bit more thought:

Is it important to distinguish between VoIP and cellular calls? If so,
we'll have to think about how to achieve that. My inclination is to defer
that until (much) later.

Are there ever going to be any clients we would want to install
disabled-by-default? (Perhaps some of the things in gnome-games?)
If so, then we'd have to do something more like this:

      property Handler.EnableByDefault: read-only boolean
          If True, this Handler is enabled by default. In older
          Handler implementations where this property is not present,
          it MUST be assumed to be True.

      property ChannelDispatcher.EnabledHandlers: a{sb}
          If { client: True } appears in this map, that client is enabled.
          If { client: False } appears in this map, that client is disabled.
          If a client is not a key in this map, that client is enabled
          or disabled according to its EnableByDefault property.

      method ChannelDispatcher.SetHandlerEnabled(s: client, b: enabled)
          -> nothing

      method ChannelDispatcher.ResetHandlerEnabled(s: client)
          -> boolean: now_enabled
          Remove that client from EnabledHandlers, returning it to its
          default state. Return its EnableByDefault property.

This is still fairly simple, and seems a lot easier to document than matching
channel classes. I think my preferred solution is this one: it adds a
significant amount of flexibility without adding much complexity.

If we want to make this per-account later, the design with EnabledHandlers
doesn't rule that out: each Account could have its own EnabledHandlers
property, with the precedence being Account > ChannelDispatcher > default.

I specifically do not want the Telepathy spec to depend on GSettings; the way
you configure "global" Telepathy things, or Telepathy accounts, should be to
call D-Bus methods on the AccountManager, ChannelDispatcher or Account. If
Mission Control wants to use GSettings to store the EnabledHandlers, that's
fine, but it should be private to MC (although personally I'd be inclined to
use a GKeyFile in ~/.config).

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