我最近一直在使用ejabberd中的新MUC-Sub模块 - 用例是我需要在我的移动应用程序中使用类似WhatsApp的永久房间。在我进一步使用MUC / Sub之前，ejabberd专家可以就以下概念发表意见吗？我可能缺乏对ejabberd的全面了解，因此是基本问题。或者请让我知道一个好地方，以便更好地了解下面的内容......我已经详细研究了这两个链接（https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/和https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/）。谢谢！
基本上，如果我们需要一个MUC房间在所有用户离线时停止销毁，我们是否可以简单地禁用该功能 - 这样即使参与者离开或房间为空，服务也会继续运行。仍然可以使服务继续指向加入房间的原始房间参与者，并且如果在房间中发送消息，则消息将在每个参与者的流上排队。如果参与者离线，则该消息将进入他/她的离线消息列表（而不是MUC-Sub当前正在使用的存档/ MAM）。为什么我们需要依赖Pub-Sub和MAM模型，如果这个问题可以通过简单地保留参与者在房间中的参考来解决（即使在他/她离线后），然后利用mod_offline模块（应该发生）自动地）。
我确信这里有一个根本原因可以忽视，但是如果有人可以请一些亮点，那就太感激了！
答案 0 :(得分：0)
正如博客文章所解释的那样，这不是关于保持聊天室活着的问题。用户在离线或重新连接时无法接收推送的事实（如果他们不再次加入）是因为MUC基于在线状态。不在房间内的用户不是房间的占用者，也不应该接收任何东西。
我建议您再次仔细阅读XEP-0045 MUC和MUC Sub blog post。 MUC Sub解决的问题应该更加明显。
如果你这样做，你会注意到XEP-0045定义了持久性MUC的想法：
持久房间 如果最后一个乘客离开，房间不会被破坏;反义词：临时房间。
ejabberd中的默认设置是在用户加入时将房间创建为临时房间，但可以更改房间的设置以使其变为持久性。在这种情况下，当最后一个乘客离开时它不会被销毁。您需要更改房间配置选项（与您在该房间启用MUC Sub时使用的相同形式）。
您通常希望将此选项与MUC Sub启用相结合，以便即使没有用户，也可以保留MUC房间。