Salut has a problematic representation of ContactCapabilities (Bug #53166) which does not cache the capabilities of each known client. As a result, each channel manager is responsible for remembering its part of the cache instead. The one in ytstenut-plugins remembers and unions the data forms describing Yts services, but not the set of capability URIs representing "interest" in PEP nodes. As a result, each Ytstenut connection will lose interest in the PEP nodes in which it should have been interested whenever it creates a new transient Client, such as the one in telepathy-glib used for request-and-handle. The long-term solution is to fix Bug #53166 and rework the Salut plugin to be more like the Gabble plugin, but for now we can just extend the caching behaviour.
Created attachment 65182 [details] [review] ytst_caps_manager_represent_client: in Salut, remember caps, not just forms Otherwise we lose our interest in services' statuses whenever a new Ytstenut client is added - even if it's just a temporary one for the request-and-handle pattern.
Comment on attachment 65182 [details] [review] ytst_caps_manager_represent_client: in Salut, remember caps, not just forms Review of attachment 65182 [details] [review]: ----------------------------------------------------------------- OK, except for ::: plugin-base/caps-manager.c @@ +179,5 @@ > +add_to_set (gpointer key, > + gpointer value, > + gpointer user_data) > +{ > + DEBUG ("%s", (const gchar *) key); You probably didn't intend to leave... @@ +188,5 @@ > add_to_array (gpointer key, > gpointer value, > gpointer user_data) > { > + DEBUG ("%s", (const gchar *) key); ... these here? If you did, please at least make them more useful ("client X: Y interests" or alike?)
Pushed, without the DEBUG().
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.