ejabberd MUCとサブクラス化

Question

私は最近、ejabberdの新しいMUC-Subモジュールで遊んでいました。私のモバイルアプリケーションにはWhatsAppのような永続的な部屋が必要です。私はMUC/Subを使うことに入る前に、ejabberdのエキスパートが以下のコンセプトを参考にしてください。おそらく私の部分では、ejabberdの完全な知識の欠如、したがって基本的な質問です。そうでなければ、以下のことを理解し始めるのに良い場所を教えてください...私はすでにこれら2つのリンクを詳しく調べました（https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/とhttps://docs.ejabberd.im/developer/proposed-extensions/muc-sub/）。ありがとう！

基本的に、すべてのユーザーがオフラインになったときにMUCルームが破棄されなくても、その機能を無効にすることはできないため、参加者が退室してもルームが空であってもサービスが継続します。部屋に入室した元の部屋の参加者を引き続き指し示すようにサービスを引き続き行うことができます。部屋にメッセージが送信された場合、メッセージは各参加者のストリームで待ち行列に入ります。参加者がオフラインの場合、MUC-Subが現在利用しているアーカイブ/ MAMの代わりにオフラインメッセージリストにメッセージが入力されます。この問題が部屋に参加者のリファレンスを保持するだけで（オフラインになっても）、その後mod_offlineモジュールを利用することでPub-SubとMAMモデルに頼る必要があるのはなぜですか自動的に）。

ここに根本的な理由があることは間違いないと思います。

Answer 1

ブログの記事で説明しているように、これはチャットルームを生き生きとしておくかどうかについては問題ではありません。オフライン時または再接続時にユーザーがプッシュを受信できないという事実は、MUCがプレゼンスに基づいているためです。部屋に存在しないユーザは、部屋の占有者ではなく、何も受け取らないことになっている。

XEP-0045 MUCとMUC Sub blog postをもう一度お読みください。 MUC Subの問題をより明確にする必要があります。

あなたがそれを行う場合は、そのXEP-0045は、永続的なMUCのアイデアを定義わかります。

永続ルーム 最後の乗員終了した場合に破壊されていない部屋。 antonym：一時的な部屋。

ejabberdのデフォルトは、ユーザーが参加したときに一時的な部屋を作成することですが、その部屋の設定を変更して永続的にすることができます。その場合、それは最後の乗員が離れるときには破壊されない。あなたは部屋の構成オプションを変更する必要があります（この部屋でMUC Subを有効にしたのと同じフォーム）。

一般的には、このオプションをMUC Sub Enableと組み合わせて、ユーザーがいなくてもMUCルームを囲んでおく必要があります。