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 | ||
| README.md | ||
| setup-pattern.md | ||
README.md
Experiments
This directory contains experiments, work-in-progress crates, or other code and documentation, that
do not fall under the same stability guarantees as the main crates (matrix-sdk,
matrix-sdk-crypto, etc.).
Lab projects might be abandoned and possibly removed at any time.
That said, this directory is meant to freely explore unconventional or interesting ways the Matrix Rust SDK can evolve, feel free to propose an experiment.
Current experiments
TBD
Archived experiments
Link to PR that deleted the experiment from the repo, newest first: