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