mirror of
https://github.com/matrix-org/matrix-rust-sdk.git
synced 2026-05-09 08:27:32 -04:00
a2dcfa905f
This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.
Jack-in
your experimental terminal to connect to matrix via sliding sync
A simple example client, using sliding sync to jack in to matrix via the sliding-sync-proxy.
Use:
You will need a running sliding sync proxy for now.
From the roof of this workspace, run jack-in via cargo run -p jack-in . Please note that you need to specify the access-token and username, both can be done via environment variables, too. As well as the homeserver (or http://localhost:8008 will be assumed). See below for how to acquire an access token.
Your experimental sliding-sync jack into the matrix
Usage: jack-in [OPTIONS] --user <USER>
Options:
-p, --password <PASSWORD>
The password of your account. If not given and no database found, it will prompt you for it [env: JACKIN_PASSWORD=]
--fresh
Create a fresh database, drop all existing cache
-l, --log <LOG>
RUST_LOG log-levels [env: JACKIN_LOG=] [default: jack_in=info,warn]
-u, --user <USER>
The userID to log in with [env: JACKIN_USER=]
--store-pass <STORE_PASS>
The password to encrypt the store with [env: JACKIN_STORE_PASSWORD=]
--flames <FLAMES>
Activate tracing and write the flamegraph to the specified file
--sliding-sync-proxy <PROXY>
The address of the sliding sync server to connect (probs the proxy) [env: JACKIN_SYNC_PROXY=] [default: http://localhost:8008]
--full-sync-mode <FULL_SYNC_MODE>
Activate growing window rather than pagination for full-sync [default: paging] [possible values: growing, paging]
--limit <LIMIT>
Limit the growing/paging to this number of maximum items to caonsider "done"
--batch-size <BATCH_SIZE>
define the batch_size per request
--timeline-limit <TIMELINE_LIMIT>
define the timeline items to load
-h, --help
Print help information
Get the access token
- In element.io navigate to
Settings->Help & About, under Advanced (on the bottom) you can find your Access token - Copy it and set as the
JACKIN_SYNC_TOKENenvironment variable or as--tokencli-parameter on jack-in run