XMPP in Clayster
Each entity in XMPP has a unique address, sometimes referred to as a JID. The XMPP address is commonly formatted in the user-based pattern user@domain/resource or for a server component simply as domain.
The resource may be described as a session id for the user. If the resource is excluded it is commonly referred to as a bare address or bare JID.
In Clayster the bare address is often used when describing access rights or permissions.
Presence and Roster
XMPP supports uni- or bi-directional subscriptions on another entities presence. This allows one entity to know if it’s “friend” is online or not. The “friends list” of an entity is commonly referred to as the Roster.
In a unidirectional presence subscription entity A may know when entity B comes online but entity B will not know when entity A comes online. In a bidirectional presence subscription both entities will know when the other comes online.
In Clayster presence subscription is commonly not needed and shall not be used. However when exchanging data a presence subscription shall be set up between data exchanging entities.
XML Payloads and Stanzas
In XMPP all data is XML. Since the stream is a continuous stream each message must be wrapped in an xml element. In XMPP you have a few different carbons called stanzas.
The stanzas in XMPP are;
- Message – Used to send arbitrary payload between entities.
- IQ – Used to send arbitrary payload between entities in a Info/Query pattern.
- Presence – Used to inform an entity of a friend’s presence.
In Clayster messages are commonly used because it requires no presence subscription. However, in data exchange IQ messages are commonly used and there for a presence subscription must be established.
The presence stanza is usually handled by the XMPP library.