moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

Add a use case to entity versioning

Browse Source 
Also:

  Minor typo and wording fixes
  Fix broken example XML
  More tabbing fixes
This commit is contained in:
Sam Whited 2015-08-27 16:22:55 -05:00 committed by Matthew A. Miller
parent d6b3f54e00
commit b3725e2cf9
1 changed files with 20 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
inbox/entityversioning.xml
View File

@ -50,12 +50,11 @@
This problem of "downloading the world" (downloading the entire roster
every time a session is initialized) 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 (eg. MUC
disco#items). Furthermore, roster versioning requires that the server
maintain a great deal of state (multiple versions of the roster) which can
be difficult to implement in a large, distributed system. This XEP defines
a method by which entities other than the roster can be versioned and
cached.
for the roster, it didn't account for other entities (eg. disco items).
Furthermore, roster versioning requires that the server maintain a great
deal of state (multiple versions of the roster) which can be difficult to
implement in a large, distributed system. This XEP defines a method by
which entities other than the roster can be versioned and cached.
</p>
</section1>
@ -115,6 +114,11 @@
client can fetch the list, and then poll for changes at a later date
without re-requesting the entire list.
</li>
<li>
A client wishes to cache the features supported by servers of the
contacts in their roster since their disco items is not likely to
change often.
</li>
</ul>
</section2>
<section2 topic='Servers' anchor='server_use_cases'>
@ -201,7 +205,7 @@
<!-- Server -->
<iq from='romeo@montague.lit' id='56' to='romeo@montague.lit/home' type='result>
<query xmlns='jabber:iq:roster'>
<item subscription='both' jid='bill@shakespeare.lit' />
<item subscription='both' jid='bill@shakespeare.lit'>
<version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version>
</item>
</query>
@ -218,7 +222,7 @@
<!-- Server -->
<iq from='romeo@montague.lit' id='ah382g678jka7' to='romeo@montague.lit/home' type='set'>
<query xmlns='jabber:iq:roster' ver='ver34'>
<item jid='tybalt@shakespeare.lit' subscription='remove>
<item jid='tybalt@shakespeare.lit' subscription='remove'>
<version xmlns='urn:xmpp:entityver:0'>XWE4MUUP</version>
</item>
</query>
@ -346,7 +350,7 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
</p>
<p>
Version tokens SHOULD always be considered opaque to the client (eg. even
if the version token is a derivable and consistant hash on the server side,
if the version token is a derivable and consistent hash on the server side,
clients should not need to know how the server is calculating the token).
</p>
<p>