From 8f22cf6cb889e9769d38777d75005635515306a9 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Wed, 20 Apr 2016 14:59:38 +0100 Subject: [PATCH] Minor rewording/grammar --- .../howtos/client-server-migrating-from-v1.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/supporting-docs/howtos/client-server-migrating-from-v1.rst b/supporting-docs/howtos/client-server-migrating-from-v1.rst index 8e8e2b02..d96daa1d 100644 --- a/supporting-docs/howtos/client-server-migrating-from-v1.rst +++ b/supporting-docs/howtos/client-server-migrating-from-v1.rst @@ -51,11 +51,11 @@ following summary may be useful to compare with ``v1``: * 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 must perform another fetch to incrementally obtain - more of them. In the ``/sync`` API the result always contains up to the most - recent event; creating a gap if this would be more events than the requested - limit. If this occurs then the client can use the ``prev_batch`` token as a - reference to obtaining more. + returned and the client had to perform another fetch to incrementally obtain + more of them. In the ``/sync`` API the result always contains the most + recent events, creating a gap if this would be more events than the + requested limit. If this occurs then the client can use the ``prev_batch`` + token as a reference to obtaining more. 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