Difference between revisions of "XMPPComponentProtocol"

From XMPP WIKI
Jump to navigation Jump to search
m
(One intermediate revision by the same user not shown)
Line 1: Line 1:
= XMPP Component Protocol =
+
== XMPP Component Protocol ==
 
+
The Jabber network has long included a wire protocol that enables trusted components to connect to Jabber servers. This has since been documented in the [http://xmpp.org/extensions/xep-0114.html Jabber Component Protocol specification (XEP-0114)]. This page documents arguments for and requirements of a superseding protocol.
The Jabber network has long included a wire protocol that enables trusted components to connect to Jabber servers. This has since been documented in the [http://www.jabber.org/jeps/jep-0114.html Jabber Component Protocol specification (JEP-0114)]. This page documents arguments for and requirements of a superseding protocol.
 
 
 
== Arguments  ==
 
  
 +
=== Arguments  ===
 
Arguments for wanting a replacement component protocol:
 
Arguments for wanting a replacement component protocol:
 
 
* Have XMPP 1.0 XML Streams
 
* Have XMPP 1.0 XML Streams
* More intricate JEPs that require access to user information like roster and presence. An example is the [http://www.jabber.org/jeps/jep-0163.html Personal Eventing Protocol (JEP-0163)].
+
* More intricate XEPs that require access to user information like roster and presence. An example is the [http://xmpp.org/extensions/xep-0163.html Personal Eventing Protocol (XEP-0163)].
 
* Handle several JIDs through one connection
 
* Handle several JIDs through one connection
  
== Links ==
+
=== Links ===
[http://jabberd.jabberstudio.org/dev/docs/component.shtml Jabberd2's component protocol]
+
[http://codex.xiaoka.com/wiki/_media/jabberd2:component.html Jabberd2's component protocol]
 
 
== Current discussions ==
 
  
 +
=== Current discussions ===
 
The most likely approach to improve the protocol is:
 
The most likely approach to improve the protocol is:
 
* First define a simple API of target operations.
 
* First define a simple API of target operations.
* Propose an XMPP formalism for the API using "adhoc commands" that cna be handled by the server.
+
* Propose an XMPP formalism for the API using "adhoc commands" that can be handled by the server.
  
 
One of the first target in the API is roster item addition (with nickname and subscription) and deletion.
 
One of the first target in the API is roster item addition (with nickname and subscription) and deletion.
  
== Restrictions to remove ==
+
=== Restrictions to remove ===
 
 
 
We discussed the removal of the restriction in XEP-0114 that prevent a component to send packets on the behalf of a user of the server itself.
 
We discussed the removal of the restriction in XEP-0114 that prevent a component to send packets on the behalf of a user of the server itself.

Revision as of 16:29, 21 July 2010

XMPP Component Protocol

The Jabber network has long included a wire protocol that enables trusted components to connect to Jabber servers. This has since been documented in the Jabber Component Protocol specification (XEP-0114). This page documents arguments for and requirements of a superseding protocol.

Arguments

Arguments for wanting a replacement component protocol:

  • Have XMPP 1.0 XML Streams
  • More intricate XEPs that require access to user information like roster and presence. An example is the Personal Eventing Protocol (XEP-0163).
  • Handle several JIDs through one connection

Links

Jabberd2's component protocol

Current discussions

The most likely approach to improve the protocol is:

  • First define a simple API of target operations.
  • Propose an XMPP formalism for the API using "adhoc commands" that can be handled by the server.

One of the first target in the API is roster item addition (with nickname and subscription) and deletion.

Restrictions to remove

We discussed the removal of the restriction in XEP-0114 that prevent a component to send packets on the behalf of a user of the server itself.