When we join a MUC, the initial presence we send it includes <x xmlns=...muc.../>. This is correct. When Gabble changes its presence, it send the result of wocky_muc_create_presence() for each MUC. This includes <x xmlns=...muc.../>, which is incorrect. The symptom here is that if you're in a M-Link-hosted MUC ——— — like conference.jabber.org — whenever you change your status you get all the scrollback re-delivered to you. From jdev@cjo: Kev: Check you're not sending the join element in every presence update. MattJ: It shouldn't include <x xmlns=...muc...> in the presence Kev: [if you do,] the server says "Oh, I thought they were here, but they're clearly saying they're not here and they want to join. Well, I'd better resend them the history then, they won't have that if they haven't joined yet".
Just checked the history, and this behaviour was the same in Gabble 0.8. I suppose we should add a gboolean join parameter to wocky_muc_create_presence() or similar.
I started fixing this. Here is my branch: http://git.collabora.co.uk/?p=user/wjt/wocky.git;a=shortlog;h=refs/heads/muc-presence Unfortunately when I tried to update Gabble accordingly, it turns out that Gabble is not up to speed with Wocky master, and needs fixing up for changes in the connector. So I gave up. :)
Here are a pair of branches: http://git.collabora.co.uk/?p=user/wjt/wocky.git;a=shortlog;h=refs/heads/muc-presence wocky/wocky-muc.c | 32 ++++++++++---------------------- wocky/wocky-muc.h | 3 +-- 2 files changed, 11 insertions(+), 24 deletions(-) http://git.collabora.co.uk/?p=user/wjt/telepathy-gabble-wjt.git;a=shortlog;h=refs/heads/muc-presence lib/ext/wocky | 2 +- src/call-muc-channel.c | 6 ++-- src/muc-channel.c | 49 +++++++------------------ src/muc-channel.h | 3 +- src/muc-factory.c | 2 +- src/tubes-channel.c | 79 +++++++++++++++++++--------------------- tests/twisted/muc/test-muc.py | 16 +++++++- tests/twisted/mucutil.py | 14 ++++++- 8 files changed, 83 insertions(+), 88 deletions(-) My negative-diff karma is looking good!
Damnit, this breaks some tubes tests.
(In reply to comment #4) > Damnit, this breaks some tubes tests. I fixed those tests. They were erroneously asserting that the element was present. I discussed the rationale for M-Link's behaviour with the M-Link developers, and they convinced me that their behaviour is sensible. There are basically two cases you might want to recover from: 1. The server thinks you're in the MUC, but the client doesn't. Apparently this actually does happen in practice. Without M-Link's behaviour, when the client tries to join the MUC the server misconstrues it as a presence update, so it echoes it back to you. Now your client thinks it's in the MUC, but the full user list hasn't been pushed to it, nor the topic, etc. etc. With M-Link's behaviour, when you try to join the server thinks “oh, maybe they weren't in the room after all” and treats your join as a join. 2. The server thinks you're not in the MUC, but the client thinks it is. With Gabble's current behaviour, sending a presence update to a MUC looks like a join. But with the change in behaviour, the bare presence update also looks like a join, albeit a groupchat 1.0 (pre-XMPP) join. So this works too. So all in all I think this change is good.
I endorse these initiatives.
Fixed in git for 0.11.4. I can't really be bothered to backport this change to 0.10.
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.