We need to know about more transitions for local-echo status changes, so raise
localEchoUpdated events for each transition.
Fixes an issue where we weren't turning failed transmissions red, because the
timeline wasn't being updated.
* This should fix the problem where we could end up with two concurrent syncs
due to both retrying /sync and hitting /versions. There is now one and only
one mechanism for connection recovery.
* Hit /versions a little less often as I think every 2 seconds is a little
over-aggressive. Also introduce randomness to minimize possibility of
thundering herds.
* Add a listener for the 'online' event in case any browser is nice enough
to ever fire it.
* Treat a 400 response from /versions as successful since older synapses
will not support it.
After /send completes, we check the room to see if the echo has already come
back via /sync. It's a bit of an edge-case, but we ought to check all
timelines, not just the live one.
Furthermore, we now have a map from eventId to timeline, so we can handle the
case where the echo has *not* yet come back more efficiently than searching
through the whole timeline.
In order to resolve the conflict between local and remote read-receipts, try to
give precedence to the read-receipt which refers to the most recent event.
Also fix the read-receipt synthesis in _addLiveEvents so that it actually works
(drop the spurious MatrixEvent wrapper), and remove the synthesis in
recalculate() (which appears to be redundant).
This provides optional support for fetching old events via the /context API,
and paginating backwards and forwards from them, eventually merging into the
live timeline.
To support it, events are now stored in an EventTimeline, rather than directly
in an array in the Room; the old names are maintained as references for
compatibility.
The feature has to be enabled explicitly, otherwise it would be impossible for
existing clients to back-paginate to the old events after a gappy /sync.
Still TODO here:
* An object which provides a window into the timelines to make them possible to
use. This will be a separate PR.
* Rewrite the 'EventContext' used by the searchRoomEvents API in terms of an
EventTimeline - it is essentially a subset.
After much discussion, the HS will now behave the same for guests/non-guests
wrt joining a room (you get the entire room state on join). This leave "peeking"
which never triggers a join. This can be implemented for guests by doing a
room initial sync followed by a specific /events poll with a specific room_id.
This means there are 2 sync streams: /sync and the peek /events. Architected
so you can only have 1 peek stream in progress at a time (if this were arbitrary
we'd quickly run into concurrent in-flight browser request limits (5).
This change adds support to the JDK for processing the results of a room
search, as well as back-paginating the results.
It treats each search result as a 'context' object, which can itself be
backwards or forward-paginated.
