XEP-0114 如何工作？
我对 XEP-0114 的工作原理有点困惑。使用组件为域提供服务是否意味着服务器将不再代表该域执行任何操作，或者仅意味着该组件也将被允许为该域上的所有用户提供服务。
更具体地说，是否可以让多个组件服务于同一域？例如，一个组件可以处理 MUC，另一个组件可以将所有消息存储在历史存储中，第三个组件可以处理名册等...同时 XMPP 服务器继续像平常一样处理用户 - 并回复状态， iq 数据包等...这意味着必须编写组件，以便它们的领域不会相互交叉。
I am a bit confused about how XEP-0114 works. Does servicing a domain using a component mean that the server will no longer do anything on behalf of that domain, or does it just mean that the component will ALSO be allowed to service all users on that domain.
More specifically, is it possible to have multiple components servicing the same domain? For example, one component could handle MUC, another could store all messages in a history store, and a third could handle the roster, etc... All while the XMPP server continues handling the user like it normally would - and replying to presence, iq packets, etc... What this means is that components would have to be written so that their realm doesn't intersect with each other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在上面的评论中回答 @dhruvbird 的第二个问题，如果您已将一个域委托给 XEP-114 组件，则该组件负责有关该域的一切，包括用户的所有存在状态那个域。这是可能的，虽然乏味，但请确保您已阅读新的 RFC 6121最近。
注意：大多数服务器都有一个组件来实现所有这些在线状态订阅逻辑 - 这是实现真正的 IM 业务逻辑的地方。您将有效地编写该逻辑的替代品，因此首先确保没有其他方法可以解决您的问题。
Answering @dhruvbird's second question in the comments above, if you have delegated a domain to your XEP-114 component, that component is responsible for everything about that domain, including all of the presence states of the users in that domain. That is possible, if tedious, but make sure you've read the new RFC 6121 recently.
Note: most servers have a component that implements all of this presence subscription logic - it's where the real IM business logic is implemented. You'll effectively be writing a replacement for that logic, so make sure there's no other way to solve your problem first.