| Summary: | Capabilities should be revokable | ||
|---|---|---|---|
| Product: | Ytstenut | Reporter: | Robert Staudinger <robert.staudinger> |
| Component: | tp-ytstenut | Assignee: | Robert Staudinger <robert.staudinger> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | medium | CC: | olli.salli |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=45234 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
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. 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? (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. 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.
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);