Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for adding full_state param to v2 sync #133

Merged
merged 2 commits into from
Oct 28, 2015
Merged

Proposal for adding full_state param to v2 sync #133

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
13eddd4
Proposal for adding full_state param to v2 sync
richvdh Oct 26, 2015
ece4268
Clarify the interaction between full_state and timeout.
richvdh Oct 26, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 20 additions & 2 deletions api/client-server/v2_alpha/sync.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ paths:
summary: Synchronise the client's state and receive new messages.
description: |-
Synchronise the client's state with the latest state on the server.
Client's use this API when they first log in to get an initial snapshot
Clients use this API when they first log in to get an initial snapshot
of the state on the server, and then continue to call this API to get
incremental deltas to the state, and to receive new messages.
security:
Expand All @@ -40,6 +40,24 @@ paths:
description: |-
A point in time to continue a sync from.
x-example: "s72594_4483_1934"
- in: query
name: full_state
type: boolean
description: |-
Controls whether to include the full state for all rooms the user
is a member of.

If this is set to ``true``, then all state events will be returned,
even if ``since`` is non-empty. The timeline will still be limited
by the ``since`` parameter. In this case, the ``timeout`` parameter
will be ignored and the query will return immediately, possibly with
an empty timeline.

If ``false``, and ``since`` is non-empty, only state which has
changed since the point indicated by ``since`` will be returned.

By default, this is ``false``.
x-example: "false"
- in: query
name: set_presence
type: string
Expand Down Expand Up @@ -135,7 +153,7 @@ paths:
type: object
description: |-
The state of a room that the user has been invited
to. These state events may only have the `sender``,
to. These state events may only have the ``sender``,
``type``, ``state_key`` and ``content`` keys
present. These events do not replace any state that
the client already has for the room, for example if
Expand Down
2 changes: 2 additions & 0 deletions specification/client_server_api.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -659,6 +659,8 @@ This API also returns an ``end`` token which can be used with the event stream.

{{sync_http_api}}

{{v2_sync_http_api}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it doesn't hurt to include this in the specification. We should add a preamble explaining how v2 /sync is supposed to work at some point. But I don't think it's essential that we do that now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It needs a lot more context. Really I just threw this in so that there's a way to check how it comes out in the spec doc.



Getting events for a room
~~~~~~~~~~~~~~~~~~~~~~~~~
Expand Down