moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Coming online and presence caching clarification

This commit is contained in:
Steve Kille 2018-01-02 10:02:27 +00:00
parent 407ab1d2fb
commit 8e8cc537da
1 changed files with 13 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
xep-0369.xml
View File

@ -43,6 +43,9 @@
<remark><p>
Various Clarifications from Georg Lukas review:
Role Membership reword,
Participant's Node Joining clarification,
Joining Channel Clarification,
Coming online clarification,
</p></remark>
</revision> <revision>
@ -970,7 +973,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Common User Use Cases' anchor='usecases-user'>
<section3 topic='Joining a Channel' anchor='usecase-user-join'>
<p>A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. The &lt;join/&gt; is a child element of &lt;iq/&gt; element. The &lt;join/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the &lt;join/&gt; element. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;join/&gt; element.
<p>A user joins a channel by sending a MIX "join" command from one of the user's clients. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. The &lt;join/&gt; is a child element of &lt;iq/&gt; element. The &lt;join/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the &lt;join/&gt; element. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;join/&gt; element.
The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
</p>
@ -978,7 +981,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>
The user's server needs to make roster changes as part of the join functionality. Because of this, the join and leave operations need to operate indirectly.
For this reason the initial join request is sent to the local server with the MIX channel specified as an attribute to the join.
For this reason the initial join request is sent to the local server with the MIX channel specified as an attribute to the join. The join is sent from a client identified by a full JID to the user's bare JID.
</p>
<example caption="Client sends request to Local Server to Join a Channel"><![CDATA[
@ -1028,7 +1031,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
<p>
The user's server will then send the join response back to the client that made the join request. The only change is that the incoming message is addressed to bare JID and the outgoing message is addressed to client's full JID. Prior to sending this response, the user's server will make roster modifications as set out in the next section.
The user's server will then make roster modifications as set out in the next section.
After making these changes, the user's server will send the join response back to the client that made the join request, identified by the full JID. This is illustrated below:
</p>
<example caption="User's Server sends response to Client"><![CDATA[
@ -1044,6 +1048,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</join>
</iq>
]]></example>
<p>
This response informs the client that initiated the join request that the request has been completed. Note that the roster changes described in the next section will lead to roster update information being sent to all of the user's online clients, so that all of the user's clients will be updated with the new MIX channel information.
</p>
<p>
If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If at least one node is requested and none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to. This error response will also include other nodes requested where subscription failed for the same reason. </p>
@ -1519,8 +1527,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Client Coming Online and Obtaining Presence from the Local Server" anchor="usecase-obtaining-presence">
<p>
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to the server of each user subscribing to this presence node. The user's local server will then pass this presence information on to all online clients. This ensures that an online client is kept updated with presence.
When a client goes offline, it will cease getting presence updates. Presence updates will continue to flow to the user's local server, and so the local server is able maintain up to date presence state for the channel.
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to the server of each user subscribing to this presence node. The user's local server will then pass this presence information on to all online clients. This ensures that an online client is kept updated with presence.
When a client goes offline, it will cease getting presence updates. Presence updates will continue to flow to the user's local server, and so the local server is able maintain up to date presence state for the channel. The user's server MAY cache this presence information to optimize performance or MAY discard it.
</p>
<p>
When the client comes online, it will activate use of the MIX. The user's server will then send full presence status to the client using standard presence messages. This will enable the client to update presence information for the channel. Note that this does not need any interaction with the channel.