XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Component Connections

Abstract: This document specifies a standards-track XMPP protocol extension 
that enables server components to connect to XMPP servers.

URL: http://www.xmpp.org/extensions/inbox/component.html

I see this xep is very basic, concerning stream establishment and hostname binding. This is ok if we see a component just a special xmpp node, having few privileges (a fqdn, no bandwidth restrictions...), but it's limiting if we want to interact more deeply with the server and have direct control on stanza routing. For example previous (not official) component protocols with jabberd (1.x) had a <log/> option for receiving all packets, and a <route/> stanza (jabberd 2.x) for advanced routing. At present if you need to implement such features with available servers (I know pretty well the architecture of Openfire, but I think the others behave the same) you need to write components as server plugins, not as external components. This is limiting since they need to share the same host and process of the server, hindering scalability, and you are forced to use the same language of the server. What I'd like to see is some standard mechanism for external components in order to:
- register packet listeners
- register packet filters
- arbitrary routing packets
- access to the user base and active sessions

In this way we could write cross-server components with auditing, logging or other esoteric capabilities ;)

I think this could be implemented over this xep, writing one more xep specifying some <iq/> namespace for those operations. Is there any server or component developer interested in joining me for identifying the requirements and for writing such xep?

--
ByE,
FF

Reply via email to