Bug 45222 - Capabilities should be revokable
Summary: Capabilities should be revokable
Status: NEW
Alias: None
Product: Ytstenut
Classification: Unclassified
Component: tp-ytstenut (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Robert Staudinger
QA Contact:
Depends on:
Reported: 2012-01-25 03:34 UTC by Robert Staudinger
Modified: 2012-01-25 12:29 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Robert Staudinger 2012-01-25 03:34:25 UTC
It would be good if a TpYtsClient's capabilities could be revoked again, after being added.

Something along the lines of 

tp_yts_client_revoke_capability (TpYtsClient *client,
                                 const gchar *cap);
Comment 1 Olli Salli 2012-01-25 10:52:44 UTC
Note that all of names, capabilities and interests are immutable for the duration of the TpYtsClient being registered. This is because they're communicated at the Telepathy level as Handler capabilities (http://telepathy.freedesktop.org/spec/Client_Handler.html#Property:Capabilities). This ties them to the life cycle of the application, so that a connection surely no longer advertises capabilities or gets woken up for status updates some TpYtsClient application left behind after crashing or alike.

To gain dynamic subsets of capabilities / interests, one can register multiple TpYtsClients, which can be unregistered separately.

But we can add API to revoke capabilities and remove interests BEFORE registering a particular TpYtsClient though, if that is useful.
Comment 2 Robert Staudinger 2012-01-25 11:20:54 UTC
Not sure I'm understanding -- there can only be one service (-name) per TpYtsClient right? Wouldn't the dynamic capabilities have to be emulated using a swarm of services?
Comment 3 Olli Salli 2012-01-25 11:39:55 UTC
(In reply to comment #2)
> Not sure I'm understanding -- there can only be one service (-name) per
> TpYtsClient right? Wouldn't the dynamic capabilities have to be emulated using
> a swarm of services?

Technically, nothing in Telepathy prevents you from adding an another TpYtsClient for the same service name, and it would have the desired result. But it'd be a bit random which one gets incoming channels (only one of them does). So on a second thought, indeed not such a great idea.

We'll have to significantly revamp the D-Bus APIs and consequently tp-ytstenut and the salut and gabble plugins if we want to make an existing registered TpYtsClient be able to add and remove caps and interests.
Comment 4 Olli Salli 2012-01-25 12:29:09 UTC
Transcript from relevant IRC conversation:


Also of note is that in the current implementation, whenever you change the set of ytstenut caps you provide or are interested in, your advertised XMPP capabilities will change. And then, your entire contact list will have to re-discover your capabilities, unless they happen to have that exact set cached from some earlier time you had exactly those interests and caps, + other XMPP capabilities.

So it's not very sustainable to promote changing a lot the ytstenut provided or interesting caps.

We might be able to make the XMPP service discovery and interest registration a bit more finer-grained though in the future, so there's a better chance that your contacts will have one of those grains ached already. As the unit of caching is not the entire silo anymore :)


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.