定制XMPP服务器值得吗？（与拥有客户员工相比）

我被问及为内部应用程序编写ejabber模块的可能性。我反对这个想法，但我对xmpp不够熟悉，无法支持我的回答，也许我错了

当谷歌挥手时，他们选择了xmpp；我理解这种选择；多人之间的实时通信。同样的目标

…但我觉得定制的服务器插件不是正确的答案

我看到的问题是：

1您与服务器开发失去同步，必须通过merge hell来确保服务器上的安全更新、修补程序等得到修补

2任何服务器的大量定制都意味着您可能希望传递特殊的标记消息以与服务器插件交互；这意味着您还必须进行大量的客户机定制

还有一条替代路线：

标准XMPP服务器。两个定制的xmpp客户端；一个用于客户端，一个用于服务器

服务器客户端打开到XMPP服务器的连接，然后坐在那里等待

多个前端客户端打开到XMPP服务器的连接，然后使用XMPP选择性地打开连接：1个连接到彼此，2个连接到服务器客户端用户

然后，前端可以通过与服务器客户端对话来执行实时更新。它甚至可以订阅多个服务器客户端用户，并为多个不同的并发任务提供传入的“活动流”

这具有以下优点：

1您只需要在客户端库中解决一次XMPP问题

2您的应用程序服务器从外部看不到；只有XMPP服务器是外部可见的，这是一个巨大的安全胜利

3您可以使用任何您想要的XMPP服务器基础结构，而不会出现任何问题

4您将永远不会有一个服务器更新导致您的应用程序服务器成为“遗留”，并且在没有完整的XMPP协议更新的情况下无法使用这些API

缺点：

您的应用程序服务器客户端需要足够复杂，以处理多个请求，或者有多个worker或其他内容，但这会使用资源字段进行扩展，并且有来自不同机器的多个应用程序服务器连接到XMPP网络

…但是，我对这项技术不太熟悉

---

我建议的替代方案比定制的xmpp服务器更糟糕，这有什么原因吗？

xmpp在Google Wave/Wave中仅用于联邦，即仅用于服务器到服务器的通信。这是为了利用现有的XMPP功能，如发现协议。消息以二进制形式在XMPP数据包内的服务器之间传输。Web客户端使用WebSockets/Socket.IO与服务器通信。实际上，这就是为什么要争论开发一个基于纯HTTP的联合协议。

您已经详细介绍了使用XMPP的潜在解决方案，但缺少的是您试图解决的实际问题描述。这将大大有助于从具有XMPP经验的人那里获得一些帮助。例如，你反对插件的两个论点对我来说没有多大意义。如果服务器是为插件设计的，插件可以解决您的问题，那么就编写一个插件。一个插件不是很重的定制，它是一个扩展，通常应该是向前兼容的。我不认为它特别相关，但它类似于实时协作白板，客户端通过xmpp将绘图动作传递给服务器，插件将它们持久化。真的吗？对不起，我弄错了。我认为前端通过WebSocket作为某种xmpp客户端运行。我的错；我对wave的评论与此毫不相干。