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

XEP-0366: Editing for spelling, tone, and grammar

hacx
Sam Whited 2016-12-09 14:23:32 -06:00
parent 9dbc111ec3
commit e94d337aff
1 changed files with 34 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
xep-0366.xml
View File

@ -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 @@
<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 @@
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 @@
<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 @@
</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: