|
|
|
@ -26,10 +26,12 @@
@@ -26,10 +26,12 @@
|
|
|
|
|
<supersededby /> |
|
|
|
|
<shortname>EV</shortname> |
|
|
|
|
&sam; |
|
|
|
|
<author> |
|
|
|
|
<firstname>Doug</firstname> |
|
|
|
|
<surname>Keen</surname> |
|
|
|
|
</author> |
|
|
|
|
<revision> |
|
|
|
|
<version>0.1.2</version> |
|
|
|
|
<date>2016-12-21</date> |
|
|
|
|
<initials>ssw</initials> |
|
|
|
|
<remark><p>Spelling, tone, and grammar.</p></remark> |
|
|
|
|
</revision> |
|
|
|
|
<revision> |
|
|
|
|
<version>0.1.1</version> |
|
|
|
|
<date>2016-07-11</date> |
|
|
|
@ -59,17 +61,17 @@
@@ -59,17 +61,17 @@
|
|
|
|
|
<section1 topic='Introduction' anchor='intro'> |
|
|
|
|
<p> |
|
|
|
|
This problem of "downloading the world" (downloading the entire roster |
|
|
|
|
every time a session is initialized or receiving an entire disco items |
|
|
|
|
every time a session is initialized, or receiving an entire disco items |
|
|
|
|
response every time a MUC list is queried, etc.) was partially addressed by |
|
|
|
|
&xep0237; which was later merged into &rfc6121; §2.6. While this solved |
|
|
|
|
the problem for the roster, it didn't account for other entities. |
|
|
|
|
the problem for the roster, it did not account for other entities. |
|
|
|
|
Furthermore, roster versioning requires that the server maintain a great |
|
|
|
|
deal of state (roster items which should be pushed for each entity on |
|
|
|
|
reconnect, or monotonically increasing counters, etc.) which can be |
|
|
|
|
difficult to store or synchronize in a large, distributed system. This XEP |
|
|
|
|
defines a method by which generic entity lists can be versioned and cached, |
|
|
|
|
and which is optimized for distributed systems with large entity lists (but |
|
|
|
|
works equally well on small, single server deployments). |
|
|
|
|
reconnect, monotonically increasing counters, etc.) which can be difficult |
|
|
|
|
to store or synchronize in a large, distributed system. |
|
|
|
|
This XEP defines a method by which generic entity lists can be versioned and |
|
|
|
|
cached which is optimized for distributed systems with large entity lists, |
|
|
|
|
but which works equally well on small, single server deployments. |
|
|
|
|
</p> |
|
|
|
|
</section1> |
|
|
|
|
|
|
|
|
@ -79,7 +81,7 @@
@@ -79,7 +81,7 @@
|
|
|
|
|
An extra round trip MUST NOT be required to initiate entity versioning. |
|
|
|
|
</li> |
|
|
|
|
<li> |
|
|
|
|
Clients that do not implement the protocol (but which use servers that |
|
|
|
|
Clients that do not implement this protocol (but which use servers that |
|
|
|
|
do) MUST still be able to request and receive entities normally. |
|
|
|
|
</li> |
|
|
|
|
<li> |
|
|
|
@ -124,9 +126,10 @@
@@ -124,9 +126,10 @@
|
|
|
|
|
<ul> |
|
|
|
|
<li> |
|
|
|
|
A client on a mobile device where bandwidth and throughput are limited |
|
|
|
|
has a very large roster which cause connections to take an unacceptable |
|
|
|
|
amount of time. With entity versioning, connections after the first |
|
|
|
|
connection do not take as long, and use less bandwidth. |
|
|
|
|
has a very large roster which cause connecting to take an unacceptable |
|
|
|
|
amount of time. |
|
|
|
|
With entity versioning, subsequent connections after the first do not |
|
|
|
|
take as long, and use less bandwidth. |
|
|
|
|
</li> |
|
|
|
|
<li> |
|
|
|
|
A client often wants to view the list of multi-user chat rooms |
|
|
|
@ -238,21 +241,22 @@
@@ -238,21 +241,22 @@
|
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Servers that implement this protocol must assign such a version token to |
|
|
|
|
each entity that is controlled by the server. The server SHOULD then |
|
|
|
|
update this version every time any mutable property of the entity changes |
|
|
|
|
(eg. when the subscription status of a user changes). The server MAY |
|
|
|
|
choose to update this token at any time (to force the clients to |
|
|
|
|
invalidate their cached representation fo the object). This version token |
|
|
|
|
MUST then be included with every object representation of that entity |
|
|
|
|
sent down in the stream. This is done by including a sub-node called |
|
|
|
|
"version" qualified by the entity versioning XML namespace defined in |
|
|
|
|
this document. Similarly, clients MAY also add version nodes for each |
|
|
|
|
version token they possess to the request for a list (not specifying a |
|
|
|
|
version token will force the server to send information on that entity to |
|
|
|
|
the client). If a client sends up a list of version tokens, the server |
|
|
|
|
MUST then check to see if those tokens correspond to any entity which it |
|
|
|
|
knows about, and not send down any entities with matching version tokens |
|
|
|
|
in the response. |
|
|
|
|
each entity that is controlled by the server. |
|
|
|
|
The server SHOULD then update this version every time any mutable property |
|
|
|
|
of the entity changes (eg. when the subscription status of a user |
|
|
|
|
changes). |
|
|
|
|
The server MAY choose to update this token at any time (to force the |
|
|
|
|
clients to invalidate their cached representation of the object). |
|
|
|
|
This version token MUST then be included with every object representation |
|
|
|
|
of that entity transmitted in the stream. |
|
|
|
|
This is done by including a sub-node called "version" qualified by the |
|
|
|
|
entity versioning XML namespace defined in this document. |
|
|
|
|
Similarly, clients MAY also add version nodes for each version token they |
|
|
|
|
possess to the request for a list (not specifying a version token will |
|
|
|
|
force the server to send information on that entity to the client). |
|
|
|
|
If a client sends up a list of version tokens, the server MUST then check |
|
|
|
|
to see if those tokens correspond to any entity which it knows about, and |
|
|
|
|
not send down any entities with matching version tokens in the response. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
For example, a versioned roster request might look like this: |
|
|
|
|