我被問及爲內部應用程序編寫ejabber模塊的可能性。我反對這個想法，但我對xmpp不太瞭解，以支持我的迴應，也許我錯了。是否值得自定義XMPP服務器？ （與擁有客戶工作者）
當谷歌做了浪潮時，他們選擇了xmpp;我明白那個選擇;多人之間的實時通信。這裏同樣的目標。
...但感覺對我來說就像一個定製的服務器插件是不是正確的答案。
我看到的問題是：
1）你失去了同步與服務器的發展，必須要經過合併地獄，以確保安全更新，修補程序等服務器上進行修補。
2）服務器的任何大量定製意味着你可能希望路過的特殊標記的信息與服務器插件進行交互;這意味着你也必須做大量的客戶端定製。
有替代路線：
標準XMPP服務器。兩個定製的xmpp客戶端;一個用於客戶端，另一個用於服務器。
服務器客戶端打開到XMPP服務器的連接，並等待。
多個前端客戶端XMPP服務器的開放連接，然後使用XMPP到任選打開連接：1）對於彼此和2）連接到服務器的客戶端用戶。
然後，前端可以通過與服務器客戶端交談來執行實時更新。它甚至可以訂閱多個服務器客戶端用戶，併爲多個不同的併發任務傳入「活動流」。
這樣做的優點是：
1）您只需要一次（客戶端庫）
2）你的應用服務器是從來沒有外部可見的解決XMPP的問題;只有XMPP服務器在外部可見，這是巨大的安全勝利。
3）您可以使用任何您想要的XMPP服務器基礎設施而沒有任何問題。
4）你將永遠不會導致您的應用程序服務器成爲「傳統」和服務器更新無法使用這些API的話（短一個完整的XMPP協議的更新）。
缺點：
您的應用程序服務器的客戶端需要足夠複雜，處理多個請求，或者有多個工人或東西（但這種擴展使用資源領域，有不同的機器連接到XMPP網絡的多個應用服務器）。
...但是，我不熟悉這項技術。
是否有任何理由，我認爲會比定製的XMPP服務器更糟糕的選擇嗎？
對於使用XMPP的潛在解決方案，您已經進行了非常詳細的介紹，但缺少的是您試圖解決的實際問題描述。這對從XMPP經驗的人那裏獲得一些幫助很有幫助。例如，你對插件的2個參數對我來說沒有多大意義。如果服務器是專爲插件和插件解決您的問題，然後編寫一個插件。插件不是很重的定製，它是一個擴展，通常應該是向前兼容的。 – Robin
我不認爲它是特別相關的，但是有一些與實時協作白板相關的內容，客戶端通過xmpp向服務器傳達繪製操作，並且該插件保留它們。 – Doug