The src/conn-olpc.c code in telepathy-gabble uses pubsub to share data between roster users about the users icon colour, public ssh key, activity information, etc. However, by default, pubsub is a "broadcast-and-forget" system, i.e. the server will broadcast the data to any existing clients, but not save it to be queried later. Old ejabberd versions were not exactly specs-compliant here and stored the data anyway, but new ejabberd versions do not store the data by default, and this isn't configurable. This means that OLPC presence is broken - when connecting to a network, Sugar/telepathy attempts to retrieve the public keys and icon colors of all existing users on the network (via pubsub query). This fails (the server didn't store it) so the presence is broken. The pubsub messages generated by telepath-gabble/wocky should be modified to mark the data as persistent, to be stored to the server, according to http://xmpp.org/extensions/xep-0223.html. Reproduced with telepathy-gabble-0.15.3.
Those infos are stored using PEP (XEP-0163) which is a subset of pubsub. Did PEP changes to not automatically store the last element published? That sounds weird to me. XEP-0223 seems to be about storing *private* datas on the pubsub server, so I'm not sure it's related to this.
Thanks for the quick response. http://xmpp.org/extensions/xep-0163.html doesn't seem to cover our use case here, it seems to talk exclusively about a "fire and forget" model (broadcast the name of the track that the user is playing, then forget). However it is a subset of XEP-0060 which explains the persistence settings (in somewhat uncertain terms, admittedly). XEP-0223 does seem to apply to PEP, at least it talks about its applications in PEP from the start. I see http://xmpp.org/extensions/xep-0163.html#notify-last but I can't quite get my head around what it is saying. Is that the part of PEP you are trying to 'exploit' here so that OLPC key/color/activity data is available to new users connecting to the network?
Yeah when connecting one should receive the last items published on the PEP nodes of his contacts.
OK, thanks for pointing that out. Enabling jabber's last item cache helps a lot. Still a couple of problems though, and areas of uncertainty: telepathy connects to the server and the server sends the last published items of the PEP nodes of the user. telepathy broadcasts this info as signals but then forgets the information (doesn't cache it). Right? Isn't this racy? What if Sugar hasn't yet hooked up its signal handlers to this connection? It could connect too late and miss those signals. Sugar then tries to enumerate each buddy on the connection as follows: self.connection[CONNECTION_INTERFACE_BUDDY_INFO].GetProperties(handle) which causes an <iq type=get> request to be sent to the server, but in this case the jabber server returns an empty result, and I think this is correct. The specs seem to say that the jabber server has to cache or store the last item published, and send it to new clients as they connect (as you note above) due to on_sub_and_presence, but it doesn't say that the server has to then keep that info around for later and resend it on-demand. Am I missing anything here?
(In reply to comment #4) > telepathy connects to the server and the server sends the last published items of the PEP nodes of the user. telepathy broadcasts this info as signals but then > forgets the information (doesn't cache it). Right? Yes, this code is very old (5 years ago) and at this time ejabbard wasn't supporting last item sending when connecting. Ideally Gabble should cache this (as it does with location for example) so it wouldn't have to make a query each time. > Sugar then tries to enumerate each buddy on the connection as follows: > self.connection[CONNECTION_INTERFACE_BUDDY_INFO].GetProperties(handle) > > which causes an <iq type=get> request to be sent to the server, but in this case the jabber server returns an empty result, and I think this is correct. It's not. The server should return the last value published by the user. > specs seem to say that the jabber server has to cache or store the last item published, and send it to new clients as they connect (as you note above) due to > on_sub_and_presence, but it doesn't say that the server has to then keep that info around for later and resend it on-demand. Well, how is it supposed to send the last data published by each user when connecting if it does store it? :) last-item is really just there to avoid manually requesting the node for each of your contact. But we use to work fine without it.
(In reply to comment #5) > > which causes an <iq type=get> request to be sent to the server, but in this case the jabber server returns an empty result, and I think this is correct. > > It's not. The server should return the last value published by the user. Can you point out where in the specs this is described? on_sub_and_presence seems to only describe the generation of events for new subscriptions and presence changes of the subscriber, but doesn't talk about availability of such data for <iq type=get>. > Well, how is it supposed to send the last data published by each user when connecting if it does store it? :) ejabberd does store it, and it does publish it on connect. But, as far as I can see, the specs do not suggest that it has to be available at other times or through other requests. > last-item is really just there to avoid manually requesting the node for each of your contact. But we use to work fine without it. It used to work fine because old ejabberd had a bug, where it treated all pubsub data as persistent (even when persistence was not requested). This bug has now been fixed, so if we choose to work with non-persistent data we have to look carefully at the semantics of on_sub_and_presence.
(In reply to comment #6) > (In reply to comment #5) > > > which causes an <iq type=get> request to be sent to the server, but in this case the jabber server returns an empty result, and I think this is correct. > > > > It's not. The server should return the last value published by the user. > > Can you point out where in the specs this is described? Point 5 of http://xmpp.org/extensions/xep-0163.html "Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in XEP-0060." item retrieval is http://xmpp.org/extensions/xep-0060.html#subscriber-retrieve which is what's used by Gabble. > It used to work fine because old ejabberd had a bug, where it treated all pubsub data as persistent (even when persistence was not requested). This bug has now > been fixed, so if we choose to work with non-persistent data we have to look carefully at the semantics of on_sub_and_presence. They may have introduced another bug then, PEP nodes are always persisent.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/208.
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.