[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 #9 from Chandni Verma <chandniverma2112 at gmail.com> ---
Thanks for your attention on this bug.

(In reply to comment #6)

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

Comment #5 was a BASIC patch on MC to begin with.
A few more patches are lining up in order to have this problem solved which
include fixing telepathy-gabble connection manager to do the decion making
about when to emit ContactCapabilitiesChanged (which is out of scope of this
bug).

For easy tracing the following steps are in order:

 - https://bugzilla.gnome.org/show_bug.cgi?id=576376
   to enable Empathy users control when empathy-call can be used.
 - Split empathy-call as a separate process independent of empathy
(https://bugzilla.gnome.org/show_bug.cgi?id=691773)
 - patch tp-gabble to incorporate the changes.


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

Since the subject of this bug is telepathy handler clients, I don't want to
bring per account settings pulled in here. It should be sufficient if I deploy
a handler-channel-filter in empathy, like this:

 18 [org.freedesktop.Telepathy.Client.Handler.HandlerChannelFilter 3]
 19 org.freedesktop.Telepathy.Channel.ChannelType
s=org.freedesktop.Telepathy.Channel.Type.DBusTube
 20 org.freedesktop.Telepathy.Channel.TargetHandleType u=1
 21 org.gnome.GSettings.schema s=org.gnome.Empathy.call

> > 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 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 :-)

My mistake. I have renamed commit message from
"Allow-clients-to-control-their-capabilities-from-being-always-advertised" to
be 
"Correct which filters should be passed to CMs"

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

Thanks, this was bothering me much. I need to look how to define it in the
specs..

> 
> > 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 do not understand it very clearly. Since I am not dealing with account
specific filters but creating handler switches, I am unable to see how Bug
#21318 comes to help.


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

It needs to contain whole channel classes.
We also need subset matching for reading "advertise-capability" key from the
gschema given in .client (and as DBus property too, like you say).

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

The third one i.e. prevent my contacts from being able to find out that I have
a VoIP client, however hard they might try. This is the premise.

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

global and not account specific.

(In reply to comment #7)
> > If a capability of a handlier 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)
> 
> Slight technical correction here: the client doesn't necessarily even have
> to be buggy.
> 
> In XMPP Jingle, there is an implementation detail that it is difficult to
> make a VoIP call to someone whose capabilities you don't know, because you
> don't know which of the four incompatible dialects of Jingle they
> understand: you have to choose one of those dialects and hope they do.
> 
> Now that "real Jingle" is standardized and increasingly widespread, it would
> be nice to have the ability to make a speculative VoIP call to an "offline"
> contact in the hope that they are actually just invisible, and might answer
> anyway.
> 
> In SIP, there are no capabilities (and, in the feature-set we implement, no
> presence): you just have to assume that everyone does support VoIP (and is
> currently online), try calling them, and see what happens.

This bug shouldn't interfere with any of those services, hopefully.


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

Ok, none of these yet. I will create new bugs that should be spawn to track
these spin-offs.

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