From ea6ac3e40fd65fcfa35d1be5ebd11d584f2ad42c Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Wed, 20 Apr 2016 15:04:23 +0100 Subject: [PATCH] Another rewording of 'state' returned by '/sync' with 'since' parameter --- .../howtos/client-server-migrating-from-v1.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/supporting-docs/howtos/client-server-migrating-from-v1.rst b/supporting-docs/howtos/client-server-migrating-from-v1.rst index d96daa1d..5633d387 100644 --- a/supporting-docs/howtos/client-server-migrating-from-v1.rst +++ b/supporting-docs/howtos/client-server-migrating-from-v1.rst @@ -45,10 +45,6 @@ following summary may be useful to compare with ``v1``: for clients to represent state changes that occur within the region of returned timeline. - * Additionally, the ``state`` contained in the ``/sync`` response by default - only contains keys that have changed since the basis given in the ``since`` - parameter, rather than containing a full set values. - * In ``/events`` if more events occurred since the ``since`` token than the ``limit`` parameter allowed, then events from the start of this range were returned and the client had to perform another fetch to incrementally obtain @@ -57,6 +53,11 @@ following summary may be useful to compare with ``v1``: requested limit. If this occurs then the client can use the ``prev_batch`` token as a reference to obtaining more. + * Additionally, the ``state`` contained in the ``/sync`` response that has a + ``since`` parameter will contains only keys that have changed since the + basis given in the ``since`` parameter, rather than containing a full set + values. + There is no direct replacement for the per-room ``/rooms/:roomId/initialSync`` endpoint, but the behaviour can be recreated by applying an ad-hoc filter using the ``filter`` parameter to ``/sync`` that selects only the required room ID::