私は、内部アプリケーション用のejabberモジュールを書く可能性について質問されました。私はこの考えに反対していますが、私はxmppに十分に精通していないので、私の応答をサポートすることができません。おそらく私は間違っています。XMPPサーバーをカスタマイズする価値はありますか？ （対クライアントワーカー）
Googleが波を振ると、彼らはxmppを選択しました。私はその選択を理解しています。複数の人々の間のリアルタイムコミュニケーション。ここでも同じ目標。
...しかし、カスタマイズされたサーバープラグインが私には正しい答えではないように感じます。私が見
問題は、以下のとおりです。
は1）あなたは、サーバーの開発との同期を失い、パッチが適用されているサーバー上などのセキュリティアップデート、パッチを、確実にするために通過地獄をマージする必要があります。
2）サーバーの大幅なカスタマイズは、おそらくサーバープラグインとやりとりするための特別なマークアップメッセージを送ることを期待していることを意味します。つまり、クライアントのカスタマイズも大量に行う必要があります。
代替ルートがあります。
標準XMPPサーバー。 2つのカスタマイズされたxmppクライアント。 1つはクライアント用で、もう1つはサーバー用です。
サーバークライアントがXMPPサーバーとの接続を開いて、待機して待機します。
複数のフロントエンドクライアントがXMPPサーバーへの接続を開き、xmppを使用してオプションで接続を開きます（1）お互いに、2）サーバークライアントユーザーに接続します。
フロントエンドは、サーバークライアントと通信することでリアルタイム更新を実行できます。また、複数のサーバー・クライアント・ユーザーにサブスクライブし、複数の異なる並行タスクに対して「アクティビティー・ストリーム」を受信することもできます。
は、これはの利点があります：あなたは一度だけあなたのアプリケーションサーバーが外部から見えることはありません
2）（クライアントライブラリ）XMPPの問題を解決する必要が
1）。 XMPPサーバだけが外部から見えます。これは大規模なセキュリティ上の勝利です。
3）問題なく使用したいXMPPサーバーインフラストラクチャを使用できます。
4）あなたのアプリケーションサーバーは「レガシー」になり、それらのapisをもう使用できなくなります（完全なXMPPプロトコルの更新が不十分です）。
ダウンサイド：
あなたのアプリケーション・サーバー・クライアントが複数の要求を処理するのに十分な複雑される必要があり、または複数の労働者か何かを（持っていますが、これはリソースフィールドを使用してスケーリングし、XMPPネットワークに接続異なるマシンから複数のアプリケーション・サーバーを持っています）。
...しかし、私は技術に精通していません。
私が提案した代替案が、カスタマイズされたxmppサーバーよりも悪い理由がありますか？
XMPPを使用した潜在的なソリューションに関しては非常に詳細に説明されていますが、欠落しているのは解決しようとしている実際の問題の説明です。これは、XMPPの経験を持つ人々の助けを借りるのに大いに役立ちます。例えば、プラグインに対するあなたの2つの議論は、私にはあまり意味がありません。サーバーがプラグイン用に設計されていて、プラグインが問題を解決する場合は、プラグインを作成します。プラグインは大幅なカスタマイズではなく、拡張機能であり、一般的に前方互換性があります。 – Robin
私はそれは特に重要ではありませんが、クライアントがxmpp経由でサーバに描画操作を伝え、プラグインがそれらを持続させる、リアルタイムコラボレーションホワイトボードの行に沿ったものがあります。 – Doug