feat(sdk): Introduce RoomEventCacheGenericUpdate, one channel to get update of all rooms#5247
Conversation
bnjbvr
left a comment
There was a problem hiding this comment.
Really not a big fan of random renamings, as I find it confusing, as a very active developer in the event cache, to have concepts I'm working on being "disappearing" under my feet. We could probably discuss this practice in our face-to-face time, because this is really frustrating me, but maybe it doesn't have to.
Other than that, the patch makes sense to me overall. Not a huge fan of the super long name, but maybe we can find a shorter one. How do you plan to use this, out of curiosity?
andybalaam
left a comment
There was a problem hiding this comment.
Looks good, with a couple of questions. Thanks!
bc568fc to
b065439
Compare
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## main #5247 +/- ##
==========================================
+ Coverage 90.18% 90.22% +0.03%
==========================================
Files 334 334
Lines 104824 105100 +276
Branches 104824 105100 +276
==========================================
+ Hits 94540 94828 +288
+ Misses 6232 6212 -20
- Partials 4052 4060 +8 ☔ View full report in Codecov by Sentry. |
21f3a9a to
6b98245
Compare
GenericRoomEventCacheUpdate, one channel to get update of all roomsRoomEventCacheGenericUpdate, one channel to get update of all rooms
This patch fixes a comment about `RoomEventCacheState::handle_sync` returned values.
…t update of all rooms. `RoomEventCache::subscribe` is nice to subscribe to every update happening inside a room in the event cache. However, the returned `RoomEventCacheSubscriber` has side-effects when dropped (see auto-shrink to save memory space). In some situation, this is pretty annoying. for example, if one wants to listen to multiple room updates, all the room event cache subscribers must be kept in memory, thus breaking the side-effects. This isn't always the desired output. In addition, listening to multiple channels/subscribers at the same is quite complex, as it implies non-trivial async runtime efforts or complex future types. To solve this problem, this patch introduces a new `EventCache::subscribe_to_room_generic_updates` method, which returns a single `Receiver<RoomEventCacheGenericUpdate>`. First off, it hides the details of `RoomEventCacheUpdate` (returned by `RoomEventCacheSubscriber`), which might be desired, but particularly lighter because events aren't part of the payload. Second, one no longer needs to subscribe to all rooms. Only one channel can be listened to get updates for all rooms. It reduces the complexity on the caller side, plus `Receiver<RoomEventCacheGenericUpdate>` doesn't have any side-effect. This patch tests this feature in 4 situations: 1. when a room is created/loaded empty, 2. when a room is loaded and is not empty because data exists in the storage, 3. when a room receives data from the sync, 4. when a room receives data from the pagination.
6b98245 to
c30aa72
Compare
| // Create 1 room, with 4 chunks in the event cache storage. | ||
| let user = user_id!("@mnt_io:matrix.org"); | ||
| let client = logged_in_client(None).await; | ||
| let room_id = room_id!("!raclette:patate.ch"); |
RoomEventCache::subscribeis nice to subscribe to every updatehappening inside a room in the event cache. However, the returned
RoomEventCacheSubscriberhas side-effects when dropped (seeauto-shrink to save memory space). In some situation, this is pretty
annoying. for example, if one wants to listen to multiple room updates,
all the room event cache subscribers must be kept in memory, thus
breaking the side-effects. This isn't always the desired output. In
addition, listening to multiple channels/subscribers at the same is
quite complex, as it implies non-trivial async runtime efforts or
complex future types.
To solve this problem, this patch introduces a new
EventCache::subscribe_to_room_generic_updatesmethod, which returns asingle
Receiver<RoomEventCacheGenericUpdate>.First off, it hides the details of
RoomEventCacheUpdate(returned byRoomEventCacheSubscriber), which might be desired, but particularlylighter because events aren't part of the payload.
Second, one no longer needs to subscribe to all rooms. Only one channel
can be listened to get updates for all rooms. It reduces the complexity
on the caller side, plus
Receiver<RoomEventCacheGenericUpdate>doesn'thave any side-effect.
This patch tests this feature in 4 situations: