Bug 49335 - rename UpdateCapabilities to SetCapabilities?
Summary: rename UpdateCapabilities to SetCapabilities?
Status: RESOLVED NOTABUG
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: tp-spec-1.0
  Show dependency treegraph
 
Reported: 2012-05-01 05:59 UTC by Jonny Lamb
Modified: 2012-05-01 06:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Jonny Lamb 2012-05-01 05:59:20 UTC
In all the implementations worth anything, ContactCaps.UpdateCapabilities acts more like a Set operation because it resets all previous caps.

Update feels like the CM is keeping a list of clients and calling UpdateCaps with only one client won't lost all other clients, but that's wrong.

So, how about renaming this to SetCapabilities?
Comment 1 Jonny Lamb 2012-05-01 05:59:57 UTC
(Let me know if I've misunderstood something here!)
Comment 2 Simon McVittie 2012-05-01 06:08:36 UTC
(In reply to comment #0)
> In all the implementations worth anything, ContactCaps.UpdateCapabilities acts
> more like a Set operation because it resets all previous caps.

o rly? The spec says it shouldn't.

> Update feels like the CM is keeping a list of clients and calling UpdateCaps
> with only one client won't lost all other clients, but that's wrong.

Calling UpdateCaps with only one client isn't meant to lose all the other clients.

Here is how UpdateCaps is meant to work, in Python-like pseudocode:

    class Connection:
        handlers = {}

        def UpdateCapabilties (self, Handler_Capabilities):
            for (handler, filters, tokens) in Handler_Capabilities:
                if filters or tokens:
                    self.handlers[handler] = (filters, tokens)
                else:
                    del self.handlers[handler]

(This is the only thing that can work if you don't have an equivalent of Mission Control, and is just as good as "set" if you do.)
Comment 3 Jonny Lamb 2012-05-01 06:22:06 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > In all the implementations worth anything, ContactCaps.UpdateCapabilities acts
> > more like a Set operation because it resets all previous caps.
> 
> o rly? The spec says it shouldn't.

I was looking at this:

http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/connection.c#n3375

It turns out no caps channel manager implements reset_capabilities after all though.

I think you're right though, ignore me.
Comment 4 Simon McVittie 2012-05-01 06:23:38 UTC
(In reply to comment #2)
> Here is how UpdateCaps is meant to work, in Python-like pseudocode:
> 
>     class Connection:
>         handlers = {}

In Gabble this is self->priv->client_caps and self->priv->client_data_forms, FYI.

The Gabble implementation is pretty confusing, because gabble_caps_channel_manager_reset_capabilities() exists. It is in fact only implemented by the media factory, where it sets "use Call" to FALSE.

This is a bug: if you update a non-Call client, Gabble stops using Call! That's not right. The correct thing would be for GabbleConnection to maintain a set containing the clients able to do Call, and use Call whenever that set is non-empty.

As it happens, Mission Control (which does have a complete picture of everything that's going on) does treat the method as though it had "set" semantics. This avoids that bug, and is harmless in every case, except that of a disappearing handler: the spec implies that Mission Control should call UpdateCapabilities(["the.one.that.disappeared", [], []]) whenever a Handler disappears, but it does not.


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.