wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Initial Sync: Ongoing > Draft with additional work

Browse source 
Descoped some points to v2.1 as discussed irl.
This commit is contained in:
Kegsay 2015-01-12 15:52:19 +00:00
parent 8fc472c13c
commit e2894045d5
1 changed files with 35 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

19
drafts/general_api.rst
View file

@ -32,6 +32,8 @@ Version 2.1
- Comments (relates_to key) - Comments (relates_to key)
- Contextual messages (view messages around an arbitrary message) - Contextual messages (view messages around an arbitrary message)
- Rejecting invites - Rejecting invites
- State event pagination (e.g. from initial sync)
- Initial sync pagination (e.g. X most recent rooms)
Out of scope Out of scope
------------ ------------
@ -106,24 +108,21 @@ Notes:
allow APIs which use filtering to ALSO specifiy query parameters to tweak the allow APIs which use filtering to ALSO specifiy query parameters to tweak the
filter. filter.
Global initial sync API ``[ONGOING]`` Global initial sync API ``[Draft]``
------------------------------------- -------------------------------------
.. NOTE:: .. NOTE::
v2.1:
- Will need some form of state event pagination like we have for message events - Will need some form of state event pagination like we have for message events
to handle large amounts of state events for a room. Need to think of the to handle large amounts of state events for a room. Need to think of the
consequences of this: you may not get a ``m.room.member`` for someone's consequences of this: you may not get a ``m.room.member`` for someone's
message and so cannot display their display name / avatar. Do we want to message and so cannot display their display name / avatar. Do we want to
provide pagination on an event type basis? provide pagination on an event type basis?
- Handle paginating initial sync results themselves (e.g. 10 most recent rooms) - Handle paginating initial sync results themselves (e.g. 10 most recent rooms)
- No need for state events under the 'state' key to have a ``prev_content``.
Can also apply some optimisations depending on the direction of travel when
scrolling back.
- Do we want to treat global / specific room initial syncs as separate entities?
Aren't they just a filter?
Inputs: Inputs:
- A way of identifying the user (e.g. access token, user ID, etc) - A way of identifying the user (e.g. access token, user ID, etc)
- Filter to apply - Filter to apply (e.g. a single room ID for a 'room initial sync')
- Chunk token (for incremental deltas) - Chunk token (for incremental deltas)
Outputs: Outputs:
- For each room the user is joined: - For each room the user is joined:
@ -143,7 +142,11 @@ Compacting notes:
messages: [ event_id, event_id, ...], messages: [ event_id, event_id, ...],
state: [ event_id, event_id, ...], state: [ event_id, event_id, ...],
} }
Duplicate content notes:
- For non-compacted state events, duplicate state events in the ``messages`` key need to
have a ``prev_content`` to correctly display the state change text. This is not required
for ``state`` key events, which just represent the *current* state and as such do not
need a ``prev_content``. Compacted state events will need to specify the ``prev_content``.
What data flows does it address: What data flows does it address:
- Home screen: data required on load. - Home screen: data required on load.