[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 #6 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
> Subject: [PATCH] Allow-clients-to-control-their-capabilities-from-being-always-advertised

Git-commit-messages-don't-conventionally-have-words-chained-together-like-this.

-        if (space == NULL || space[1] == '\0' || space[2] != '\0')
+        if (space == NULL || !(space[1] != '\0' && space[2] != '\0'))

Sorry, I don't see how this does what it says in the Subject. It looks as
though you're fixing (or at least changing) some sort of parsing bug: which
strings are now accepted which weren't before, or which strings were accepted
before but aren't any more?

(In reply to comment #1)
> This can be made possible by [...]
> a GSetting schema path to search for boolean keys (say,
> "filter1_enabled", "filter2_enabled" and so on for all filters)

I don't think we want Telepathy to depend on GSettings in this way: Telepathy
is not GNOME-specific, and all account settings currently live on Telepathy
Account objects where they can be manipulated over D-Bus. I would like that to
continue if at all possible.

> If what I propose is implemented, a client would not need to
> start an application explicitly to show capabilities provided
> by that application (like empathy-call or glchess) to his contacts.
...
> No need to keep handler loaded for featuring capabilities or
> anticipating channel reqests.

This is already meant to be true; if the application is bus-activatable (has a
D-Bus .service file), Mission Control will advertise its capabilities. If you
don't want Mission Control to bus-activate it to ask it for its capabilities,
you also have to provide a .client file containing a cache of those
capabilities.

If our parsing of .client files is incorrect, then it might interfere with what
I just described. If so, please explain what's wrong in your patch commit
message and we can fix it :-)

> a new field in filters defined in .cient files

There is a slightly subtle design point about .client files which you might not
be aware of: they are meant to be a pure cache. If an application lacks a
.client file, or if Mission Control just "feels like it", it is able to get all
the same information from that Client over D-Bus via the Client, Handler etc.
interfaces: that's why all the fields in the .client file are defined and
documented by the corresponding D-Bus properties in telepathy-spec.

(If necessary this could be dealt with by having an array D-Bus property that
is defined to have the same number of elements as HandlerChannelFilter, in the
same order.)

> If a capability of a handler is disabled by user, there will be
> no incoming channel requests for it in the first place. Even if
> they are (by some buggy client), MC will not know the name of
> that handler capable of handling it and will not pass it in the
> list of "PossibleHandlers" to any approver which is capable of
> approving similar channels.

This is a missing feature. I would be happy to review a patch that implements
it, but I would prefer it to be done using a D-Bus property on the Account as
suggested in Bug #21318, rather than (effectively) including all of GSettings
in the Telepathy spec.

I would also prefer this to be thought of in terms of giving Mission Control
information, rather than hiding information: it shouldn't be "Mission Control
doesn't know the Handler has capability X", but rather "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".

One of the issues that needs to be settled in order to do that is the scope of
the D-Bus property, for which we need to look at its use cases. Does it need to
contain whole channel classes, or would it be sufficient to act on channel
types? Do the channel classes need to match exactly, or do we use subset
matching?

For "no VoIP", it's enough to be able to knock out the entire Call and
StreamedMedia channel types.

For "no Tubes", we could either knock out the D-Bus and Stream tube channel
types (although this raises the possibility that we add "datagram tubes" later
and suddenly need a way to suppress those too), or knock out individual tube
services (e.g. chess), or have some as-yet-undesigned way to knock out the
general concept of Tubes ("everything with interface Chan.I.Tube" maybe?) -
which one we want depends what use cases you have in mind.

I'm also not sure whether what you want here is "prevent Empathy from handling
VoIP" or "prevent *anyone* from handling VoIP", or possibly even "prevent my
contacts from being able to find out that I have a VoIP client, however hard
they try". Which is it?

Do you think this setting should be per-account or global? What would the UI
for it look like?  Which application provides the UI for it, and do individual
Handlers need to be able to tell that UI about new channel classes that it
would be meaningful to block?

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