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

80 characters

Browse source
This commit is contained in:
Kegan Dougal 2015-01-13 09:17:13 +00:00
parent e2894045d5
commit d987afe3e2
1 changed files with 16 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

29
drafts/general_api.rst
View file

@ -44,10 +44,10 @@ Version 2 API
Legend: Legend:
- ``[TODO]``: API is not in this document yet. - ``[TODO]``: API is not in this document yet.
- ``[ONGOING]``: API is proposed but needs more work. There are known issues to be - ``[ONGOING]``: API is proposed but needs more work. There are known issues
addressed. to be addressed.
- ``[Draft]``: API is proposed and has no outstanding issues to be addressed, but - ``[Draft]``: API is proposed and has no outstanding issues to be addressed,
needs more feedback. but needs more feedback.
- ``[Final]``: The API has no outstanding issues. - ``[Final]``: The API has no outstanding issues.
This contains the formal proposal for Matrix Client-Server API v2. This API This contains the formal proposal for Matrix Client-Server API v2. This API
@ -113,12 +113,13 @@ Global initial sync API ``[Draft]``
.. NOTE:: .. NOTE::
v2.1: 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
to handle large amounts of state events for a room. Need to think of the events to handle large amounts of state events for a room. Need to think of
consequences of this: you may not get a ``m.room.member`` for someone's the 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)
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)
@ -143,10 +144,11 @@ Compacting notes:
state: [ event_id, event_id, ...], state: [ event_id, event_id, ...],
} }
Duplicate content notes: Duplicate content notes:
- For non-compacted state events, duplicate state events in the ``messages`` key need to - For non-compacted state events, duplicate state events in the ``messages``
have a ``prev_content`` to correctly display the state change text. This is not required key need to have a ``prev_content`` to correctly display the state change
for ``state`` key events, which just represent the *current* state and as such do not text. This is not required for ``state`` key events, which just represent
need a ``prev_content``. Compacted state events will need to specify the ``prev_content``. 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.
@ -645,7 +647,8 @@ Inputs:
- Room ID - Room ID
- Message contents - Message contents
- Action ID (optional) - Action ID (optional)
- Whether the full event should be returned, or a compact version (default=full) - Whether the full event should be returned, or a compact version
(default=full)
Outputs: Outputs:
- The actual event sent incl content OR: - The actual event sent incl content OR:
- The extra keys added or keys modified e.g. 'content' from a policy server - The extra keys added or keys modified e.g. 'content' from a policy server