From 1058ad7653dc5dc5b3ac25d47eeed0d32e2d72f1 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 25 Sep 2025 14:51:04 +0100 Subject: [PATCH] Change 'ranges' to 'range' --- proposals/4186-simplified-sliding-sync.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/proposals/4186-simplified-sliding-sync.md b/proposals/4186-simplified-sliding-sync.md index 8b09d81db..eb4bd736b 100644 --- a/proposals/4186-simplified-sliding-sync.md +++ b/proposals/4186-simplified-sliding-sync.md @@ -244,7 +244,7 @@ The endpoint is a `POST` request with a JSON body to `/_matrix/client/unstable/o | - | - | - | - | | `timeline_limit` | `int` | Yes | The maximum number of timeline events to return per response. The server may cap this number. | | `required_state` | `RequiredStateRequest` | Yes | Required state for each room returned. | -| `ranges` | `[[int, int]]` | No | Sliding window ranges. If this field is missing, no sliding window is used and all rooms are returned in this list. Integers are *inclusive*, and are 0-indexed. (This is a list of 2-tuples.) | +| `range` | `[int, int]` | No | Sliding window range. If this field is missing, no sliding window is used and all rooms are returned in this list. Integers are *inclusive*, and are 0-indexed. (This is a 2-tuple.) | | `filters` | `SlidingRoomFilter` | No | Filters to apply to the list before sorting. | ### `RoomSubscription` @@ -350,7 +350,7 @@ An example that returns all the state except the create event: // Sliding Window API "lists": { "foo-list": { - "ranges": [ [0, 99] ], + "range": [0, 99], "required_state": { "include": [ {"type": "m.room.create", "state_key": ""}, @@ -527,14 +527,14 @@ Below are some potentially common patterns that clients may wish to use. ## Paginating room list -Pagination of the room list is achieved by the client increasing the ranges of one (or more) lists. +Pagination of the room list is achieved by the client increasing the range of one (or more) lists. For example an initial request might have a list called `all_rooms` specifying a range of `[0,19]` in the initial request, and the server will respond with the top 20 rooms (by most recently updated). On the second request the client may change the range to `[0,99]`, at which point the server will respond with the top 100 rooms that either a) weren’t sent down in the first request, or b) have updates since the first request. -Clients can increase and decrease the ranges as they see fit. A common approach would be to start with a small window +Clients can increase and decrease the range as they see fit. A common approach would be to start with a small window and grow that until the range covers all the rooms. After some threshold of the app being offline it may reduce the range back down and incrementally grow it again. This allows for ensuring that a limited amount of data is requested at once, to improve response times. @@ -573,7 +573,7 @@ time to return (if there were no updates to return). ## Pagination -In practice, having the client specify the ranges to use for the lists is often sub-optimal. The client generally wants +In practice, having the client specify the range to use for the lists is often sub-optimal. The client generally wants to have the sync request return as quickly as possible, but it doesn't know how much data the server has to return and so whether to increase or decrease the range. @@ -660,3 +660,4 @@ Changes from the initial implementation of simplified sliding sync. 7. Change the format of `required_state` in the request. 8. Move URL parameters to the request body. This is so that on web every request doesn't need to be pre-flighted for CORS. +9. Convert `ranges` to `range` in `SyncListConfig` in the request.