diff --git a/inbox/entityversioning.xml b/inbox/entityversioning.xml index 45451591..8546d25a 100644 --- a/inbox/entityversioning.xml +++ b/inbox/entityversioning.xml @@ -52,9 +52,13 @@ which was later merged into &rfc6121; ยง2.6. While this solved the problem 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. + 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 the roster and entities other than the roster can + be versioned and cached, and which is optimized for distributed systems + with large enity lists (but works equally well on small, single server + deployments).
@@ -268,6 +272,51 @@ question when a version token is received. +
+ When a client syncs with the server and indicates that it has a version
+ token in its cache that does not match any entity on the server (or when
+ the server wants to remove an entity from the clients cache for any other
+ reason), the server MUST reply with an empty <version/> node. When
+ the client receives such an empty version node it SHOULD purge the entity
+ from its cache. For example, the following exchange would trigger the
+ removal of 'inverness@chat.shakespeare.lit' from the cached MUC list:
+
+
+ If the client receives an indication that it should delete an item from a + list by any other means (eg. via a roster push), it SHOULD remove the + version token associated with that entity from its cache. +
+While the version token approach to caching does not require a great deal