This patch inlines `SlidingSyncRoom::latest_event` into its unique call
site: `SlidingSyncRoomExt::latest_timeline_item`.
`SlidingSyncRoom::latest_event` is not using any data from
`SlidingSyncRoom`, except the `Client`. So it can easily live somewhere
else. Our goal is to clean up `SlidingSyncRoom` as much as possible, and
to remove any kind of logic from it.
Since my investigation found that it significantly speeds up deletion of
a store on both Firefox and Chromium if you clear() it first, do that in
our migration code.
This patch removes the need to store and to update the
`SlidingSyncRoom::inner` field (of type `v4::SlidingSyncRoom`). Now,
we just need to handle the `prev_batch`, which is the only data we care
about.
Bonus: it reduces the size of the frozen sliding sync room quite much.
This patch removes the `SlidingSyncRoom::is_dm` method. It's not used
anywhere in the SDK, neither by the FFI bindings. Since this code is
still experimental, it's fine to remove public API.
This patch removes the `SlidingSyncRoom::is_initial_response` method.
It's not used anywhere in the SDK, neither by the FFI bindings. Since
this code is still experimental, it's fine to remove public API.
I think the reasoning behind using a RwLock for sync, and notably allowing multiple concurrent `.read()` lock taking was flawed: since there's no way
to identify which subpiece of the store we're reading and writing, there could be two concurrent requests to the write to the same thing at the same
time. To get rid of this possibility, this commit changes the lock to a single access only Mutex lock.
This patch removes the `room_list::Room::has_unread_notifications` and
the `::unread_notifications` methods. Since the previous commits,
the respective `SlidingSyncRoom` methods have been removed too. It's
better to use the `Deref` implementation of `room_list::Room` to
`matrix_sdk::Room` to use the correct methods.
This patch removes the `SlidingSyncRoom::has_unread_notifications`
and the `::unread_notifications` methods. It doesn't hold any relevant
information that `matrix_sdk::Room` can provide.
`SlidingSyncRoom` no longer has an `avatar_url` method.
`room_list::Room` no longer needs to check first in sliding sync then in
`Room` as a fallback.
This patch removes the `room_list::Room::avatar_url` method.
This patch also implements `Deref` for `room_list::Room` to
`matrix_sdk::Room`, to make our lifes easier.
With the previous commit, the avatar is properly synchronized with the
`Room`. The result is that `SlidingSyncRoom` no longer needs to hold
the `avatar_url`.
To update the avatar of a room, one has to look up in the state event.
That's the canonical way to do. For Sliding Sync, it means looking
inside the `required_state` field of the `v4::SlidingSyncRoom`. This
case already works and was tested.
However, a `v4::SlidingSyncRoom` comes with a direct `avatar` field.
It's another way to know the avatar URL of the room. This case was
handled and tested in `matrix_sdk::sliding_sync::SlidingSyncRoom`, but
it was never propagated into the proper sync mechanism. So when the
`avatar` field was set up, `matrix_sdk::sliding_sync::SlidingSyncRoom`
was holding this information, and the `avatar` wasn't defined in the
proper `Room`: `SlidingSyncRoom` has to look up inside the `Room` as
a fallback.
This patch is the first one to fix this “fallback” mechanism.
The `avatar` field of a `v4::SlidingSyncRoom` now triggers an update to
the new `RoomInfo::update_avatar` method (à la `update_name`), via
`process_room_properties`.
It's only used in test code, so it's not worth exposing to the SlidingSyncRoom object (and the Room already has such a timeline function, if needs be).
Doug