[Standards] Proposed XMPP Extension: Component Connections

Peter Saint-Andre stpeter at jabber.org
Thu Aug 2 21:04:50 UTC 2007


Fabio Forno wrote:
> 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. 

As a first step on which everyone can agree, yes. Additional features
will be defined in other specs that layer on top of this.

> 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. 

Correct.

> 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?

Have at it! :)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070802/ddccf2db/attachment.bin>


More information about the Standards mailing list