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?
(Let me know if I've misunderstood something here!)
(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.)
(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.
(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.