Merge branch 'master' into push

drafts/general_api.rst

@@ -111,6 +111,7 @@ Global initial sync API ``[Draft]``
       - The invite event
       - Other state info (e.g. room name, topic, join_rules to know if pubilc)
       - # members?
+
     so clients know more information about the room other than the user_id of the
     inviter, timestamp and the room ID.
 
@@ -637,7 +638,7 @@ A client may wish to send multiple actions in parallel. The send event APIs
 support sending multiple events in a batch.
  
 Inviting a user ``[ONGOING]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. NOTE::
   - Clients need to know *why* they are being invited (e.g. a ``reason`` key,
     just like for kicks/bans). However, this opens up a spam vector where any
@@ -1028,8 +1029,8 @@ relate to other events are referred to as "Child Events". The event being
 related to is referred to as "Parent Events". Child events cannot stand alone as
 a separate entity; they require the parent event in order to make sense.
 
-Bundling
-++++++++
+Bundling updates
+++++++++++++++++
 Events that relate to another event should come down inside that event. That is,
 the top-level event should come down with all the child events at the same time.
 This is called a "bundle" and it is represented as an array of events inside the
@@ -1081,8 +1082,8 @@ not update the event itself*, and are *not required* in order to display the
 parent event. Crucially, the child events can be paginated, whereas ``updates`` 
 child events cannot be paginated.
 
-Bundling
-++++++++
+Bundling relations
+++++++++++++++++++
 Child events can be optionally bundled with the parent event, depending on your 
 display mechanism. The number of child events which can be bundled should be 
 limited to prevent events becoming too large. This limit should be set by the 

drafts/model/profiles.rst

@@ -198,12 +198,11 @@ Requests that a client can make to its Home Server
 
  * get another user's Display Name / Avatar / metadata fields
 
-[[TODO(paul): At some later stage we should consider the API for:
+TODO(paul): At some later stage we should consider the API for:
 
  * get/set ACL permissions on my metadata fields
 
  * manage my ACL tokens
-]]
 
 Server-Server
 -------------

drafts/model/protocol_examples.rst

@@ -3,7 +3,9 @@ Host: ...
 Content-Length: ...
 Content-Type: application/json
 
-{
+.. code :: javascript
+
+  {
     "origin": "localhost:5000",
     "pdus": [
         {
@@ -27,7 +29,7 @@ Content-Type: application/json
         "1404381396852"
     ],
     "ts": 1404381427823
-}
+  }
 
 HTTP/1.1 200 OK
 ...
@@ -42,7 +44,9 @@ HTTP/1.1 200 OK
 Content-Length: ...
 Content-Type: application/json
 
-{
+.. code :: javascript
+
+  {
     origin: ...,
     prev_ids: ...,
     data: [
@@ -59,6 +63,6 @@ Content-Type: application/json
         },
         ...,
     ]
-}
+  }
 
 

drafts/model/rooms.rst

@@ -125,13 +125,14 @@ m.invite_level
 m.join_rules
   Encodes the rules on how non-members can join the room. Has the following
   possibilities:
-    "public" - a non-member can join the room directly
-    "knock" - a non-member cannot join the room, but can post a single "knock"
-        message requesting access, which existing members may approve or deny
-    "invite" - non-members cannot join the room without an invite from an
-        existing member
-    "private" - nobody who is not in the 'may_join' list or already a member
-        may join by any mechanism
+
+    - "public" - a non-member can join the room directly
+    - "knock" - a non-member cannot join the room, but can post a single "knock"
+      message requesting access, which existing members may approve or deny
+    - "invite" - non-members cannot join the room without an invite from an
+      existing member
+    - "private" - nobody who is not in the 'may_join' list or already a member
+      may join by any mechanism
 
   In any of the first three modes, existing members with sufficient permission
   can send invites to non-members if allowed by the "m.invite_level" key. A
@@ -263,10 +264,11 @@ resolve this:
    that duplicate requests can be suppressed. On receipt of a room creation
    request that the HS thinks there already exists a room for, the invitation to
    join can be rejected if:
-      a) the HS believes the sending user is already a member of the room (and
-         maybe their HS has forgotten this fact), or
-      b) the proposed room has a lexicographically-higher ID than the existing
-         room (to resolve true race condition conflicts)
+
+      - a) the HS believes the sending user is already a member of the room (and
+        maybe their HS has forgotten this fact), or
+      - b) the proposed room has a lexicographically-higher ID than the existing
+        room (to resolve true race condition conflicts)
       
  * The room ID for a private 1:1 chat has a special form, determined by
    concatenting the User IDs of both members in a deterministic order, such that

drafts/state_resolution.rst

@@ -27,6 +27,7 @@ all state events eventually.
 Algorithm requirements
 ----------------------
 We want the algorithm to have the following properties:
+
 - Since we aren't guaranteed what order we receive state events in, except that
   we see parents before children, the state resolution algorithm must not depend
   on the order and must always come to the same result. 

drafts/typing_notifications.rst

@@ -7,7 +7,7 @@ Client APIs
 To set "I am typing for the next N msec"::
   PUT .../rooms/:room_id/typing/:user_id
   Content:  { "typing": true, "timeout": N }
-    # timeout is in msec; I suggest no more than 20 or 30 seconds
+  # timeout is in msec; I suggest no more than 20 or 30 seconds
 
 This should be re-sent by the client to continue informing the server the user
 is still typing; I suggest a safety margin of 5 seconds before the expected

drafts/use_cases.rst

@@ -268,6 +268,7 @@ Chat Screen
  What's visible:
   - Enough scrollback to fill a "screen full" of content.
   - Threads:
+
     - Initially will only display the timestamp and user ID of the *first*
       message. But can expand to show the entire tree.
     - Tree of messages indicating which message is a reply to which.
@@ -280,6 +281,7 @@ Chat Screen
   - Desktop/Push Notifications for messages
  What you can do:
   - Send a message in reply to another message:
+
     - Immediate local echo, may cause messages to re-order
     - Messages that haven't reached the server are queued.
     - Thread is displayed where it should be in the thread order once the
@@ -296,13 +298,14 @@ Chat Screen
     The columns start and end as threads split and rejoin the main conversation
     The messages for each thread are ordered by how recent they are::
 
-    Room #1        Room # 2           Room # 2
-    +------------+ +----------------+ Side thread.
-    | * Message1 | | * Root         | +--------------+
-    | * Message2 | | * A1 -> Root   | | * B1 -> Root |
-    +------------+ | * A2 -> A1     | | * B2 -> B1   |
-                   | * M -> A2, B2  | +--------------+
-                   +----------------+
+      Room #1        Room # 2           Room # 2
+      +------------+ +----------------+ Side thread.
+      | * Message1 | | * Root         | +--------------+
+      | * Message2 | | * A1 -> Root   | | * B1 -> Root |
+      +------------+ | * A2 -> A1     | | * B2 -> B1   |
+                     | * M -> A2, B2  | +--------------+
+                     +----------------+
+
   - Typing notifications. Displayed within the correct thread/column.
 
  What you can do: