When running 0.10 with mod_csi and mod_throttle_presence, a CSI-inactive client can not reliably join MUCs, and the resulting stanza order violates XEP-0045.
A client-side MUC implementation typically only waits a certain time for the MUC join presence from the MUC, eventually timing out (due to the fact that there is no guarantee that a MUC join will ever be responded to). mod_throttle_presence unfortunately buffers this presence stanza (as well as the presence from room participants), causing a client-side timeout. If mod_throttle_presence is deactivated, joins work reliably irregardless of CSI state.
In theory, the MUC subject presence should cause the participants' presence to flush out. However, in practice this does not happen.
What I have seen looks like this instead:
>>> join presence
<<< history
<<< subject
[client-side join timeout]
[5 minute pause]
<<< presence for existing participants
<<< presence for the joining client
<<< presence updates since join
This is clearly in violation of XEP-0045 §7.2.3: "After sending the presence broadcast (and only after doing so), the service MAY then send discussion history, the room subject, live messages, presence updates, and other in-room traffic."
Thilo Molitor (tmolitor)
on
Just use mod_csi_battery_saver, this module will not reorder presences while still delaying them until a high priority stanza is sent.
Zash
on
Changes
tags Component-Community
Zash
on
This probably won't get fixed, this approached proved too problematic.
When running 0.10 with mod_csi and mod_throttle_presence, a CSI-inactive client can not reliably join MUCs, and the resulting stanza order violates XEP-0045. A client-side MUC implementation typically only waits a certain time for the MUC join presence from the MUC, eventually timing out (due to the fact that there is no guarantee that a MUC join will ever be responded to). mod_throttle_presence unfortunately buffers this presence stanza (as well as the presence from room participants), causing a client-side timeout. If mod_throttle_presence is deactivated, joins work reliably irregardless of CSI state. In theory, the MUC subject presence should cause the participants' presence to flush out. However, in practice this does not happen. What I have seen looks like this instead: >>> join presence <<< history <<< subject [client-side join timeout] [5 minute pause] <<< presence for existing participants <<< presence for the joining client <<< presence updates since join This is clearly in violation of XEP-0045 §7.2.3: "After sending the presence broadcast (and only after doing so), the service MAY then send discussion history, the room subject, live messages, presence updates, and other in-room traffic."
Just use mod_csi_battery_saver, this module will not reorder presences while still delaying them until a high priority stanza is sent.
This probably won't get fixed, this approached proved too problematic.
Changes