It was a very unclear boolean with unclear semantics, when what
we really meant was "if this is a room update and there is room
data included in this response, send back extension data".
- Complete the implementation and get UTs passing
- Get timelines/security integration tests passing
- For now, leaving out theh rest of the integration tests
Still TODO:
- Add in the remaining integration tests
- We need to remember if we have sent initial room data down
a connection. For now we just check if the room was in the window
prior to resorting, then decide based on that if we should send
initial vs delta updates. However, this falls down when a room
is both a subscription and in a list, as when it comes into the
window we add the sub to the builder, which then causes an initial
response even though we know they have it already due to the direct
room subscription.
- Refactor resort / moveRoom - it's horrible currently.
- Remove UPDATE.
- Remove getDeltaRoomData and replace with just an 'updateFields' or
equiv, as we will sometimes set deltas only to send initials later on.
Specifically:
- Remove top-level `ops`, and replace with `lists`.
- Remove list indexes from `ops`, and rely on contextual location information.
- Remove top-level `counts` and instead embed them into each list contextually.
- Refactor connstate to reflect new API shape.
Still to do:
- Remove `rooms` / `room` from the op response, and bundle it into the
top-level `rooms`.
- Remove `UPDATE` op.
- Add `room_id` / `room_ids` field to ops to let clients know which rooms each op relates to.
Along with a battery of tests to make sure we give account data only
for rooms being tracked in the sliding lists, unless it's global in
which case we just send it on.
Previously the 'initial' flag was set on the entire response which was pointless
as the client can detect this by the presence/absence of `?pos=`.
Instead, move the `initial` flag to be present on the Room object, so clients know
when to replace or update their databases. Use this to fix a bug where the timeline
would show incorrectly when clicking on rooms due to appending to the timeline when
the room subscription data was collected.
Extensions will be the main way to compartmentalise additional
/sync functionality beyond the baseline of a sliding window
and room subscriptions. Things like presence, to-device messages,
receipts, OTK counts and device lists, typing, etc can all live
as optional opt-in extensions to the core protocol.
The intention is that extensions can lean on the baseline
functionality to get information like "which rooms are present
in the sliding window" and "which rooms are directly subscribed to"
in order to aid their calculations. For example, a typing extension
may have a flag to only show typing notifications in directly
subscribed rooms (e.g rooms whose timelines are visible). To-device
extensions by comparison will just be a simple 'fetch more events'
API as it cannot make use of visible rooms in any meaningful way
as metadata is encrypted, but will make use of an explicit `since`
token to avoid implicit ACKs which plague sync v2. Presence extensions
may only load presence status for users who are joined to the
sliding window of rooms rather than all rooms. This functionality
can be provided without bogging down the logic with sliding window
handling.
- Add sync3.Response UnmarshalJSON() so we can dynamically make the
correct single/range op.
- Create sub-structs for sync2.Response to make inline embedding
easier in tests.
