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

Flesh out typing module

Browse source
This commit is contained in:
Kegan Dougal 2015-09-30 11:55:34 +01:00
parent 2b7e02c080
commit a82f2ad4ac
2 changed files with 26 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

2
specification/0-intro.rst
View file

@ -180,6 +180,8 @@ of a "Room".
Event Graphs Event Graphs
~~~~~~~~~~~~ ~~~~~~~~~~~~
.. _sect:event-graph:
Events exchanged in the context of a room are stored in a directed acyclic graph Events exchanged in the context of a room are stored in a directed acyclic graph
(DAG) called an ``event graph``. The partial ordering of this graph gives the (DAG) called an ``event graph``. The partial ordering of this graph gives the
chronological ordering of events within the room. Each event in the graph has a chronological ordering of events within the room. Each event in the graph has a

37
specification/modules/typing_notifications.rst
View file

@ -1,6 +1,13 @@
Typing Notifications Typing Notifications
==================== ====================
Users often desire to see when another user is typing. This can be achieved
using typing notifications. These are ephemeral events scoped to a ``room_id``.
This means they do not form part of the `Event Graph`_ but still have a
``room_id`` key.
.. _Event Graph: `sect:event-graph`_
Events Events
------ ------
@ -9,24 +16,28 @@ Events
Client behaviour Client behaviour
---------------- ----------------
- suggested no more than 20-30 seconds When a client receives an ``m.typing`` event, it MUST use the user ID list to
**REPLACE** its knowledge of every user who is currently typing. The reason for
this is that the server *does not remember* users who are not currently typing
as that list gets big quickly. The client should mark as not typing any user ID
who is not in that list.
This should be re-sent by the client to continue informing the server the user It is recommended that clients store a ``boolean`` indicating whether the user
is still typing; a safety margin of 5 seconds before the expected is typing or not. Whilst this value is ``true`` a timer should fire periodically
timeout runs out is recommended. Just keep declaring a new timeout, it will every N seconds to send a typing HTTP request. The value of N is recommended to
replace the old one. be no more than 20-30 seconds. This request should be re-sent by the client to
continue informing the server the user is still typing. As subsequent
Event: The client must use this list to *REPLACE* its knowledge of every user who is requests will replace older requests, a safety margin of 5 seconds before the
currently typing. The reason for this is that the server DOES NOT remember expected timeout runs out is recommended. When the user stops typing, the
users who are not currently typing, as that list gets big quickly. The client state change of the ``boolean`` to ``false`` should trigger another HTTP request
should mark as not typing, any user ID who is not in that list. to inform the server that the user has stopped typing.
{{typing_http_api}} {{typing_http_api}}
Server behaviour Server behaviour
---------------- ----------------
Servers will emit EDUs in the following form:: Servers MUST emit typing EDUs in the following form::
{ {
"type": "m.typing", "type": "m.typing",
@ -37,8 +48,8 @@ Servers will emit EDUs in the following form::
} }
} }
Server EDUs don't (currently) contain timing information; it is up to This does not contain timing information so it is up to originating homeservers
originating HSes to ensure they eventually send "stop" notifications. to ensure they eventually send "stop" notifications.
.. TODO .. TODO
((This will eventually need addressing, as part of the wider typing/presence ((This will eventually need addressing, as part of the wider typing/presence