Clarification/rewording on old and new sync-with-limit behaviour

pull/977/head
Paul "LeoNerd" Evans 9 years ago
parent 98df455a99
commit 54624f397a

@ -49,13 +49,13 @@ following summary may be useful to compare with ``v1``:
only contains keys that have changed since the basis given in the ``since`` only contains keys that have changed since the basis given in the ``since``
parameter, rather than containing a full set values. parameter, rather than containing a full set values.
* In ``/initialSync`` if the requested range contains more events than the * In ``/events`` if more events occurred since the ``since`` token than the
``limit`` parameter allows, then events from the start of this range were ``limit`` parameter allowed, then events from the start of this range were
returned and the client must perform another fetch to incrementally obtain returned and the client must perform another fetch to incrementally obtain
more of them. In the ``/sync`` API the result always contains the end of the more of them. In the ``/sync`` API the result always contains up to the most
requested range (i.e. the most recent events); possibly creating a gap. If recent event; creating a gap if this would be more events than the requested
this occurs then the client can use the ``prev_batch`` token as a reference limit. If this occurs then the client can use the ``prev_batch`` token as a
to obtaining more. reference to obtaining more.
There is no direct replacement for the per-room ``/rooms/:roomId/initialSync`` 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 endpoint, but the behaviour can be recreated by applying an ad-hoc filter using

Loading…
Cancel
Save