Conversation
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
|
will update the MSC text with the minor (non-blocking) changes before merge. |
@turt2live it looks like this got forgotten? |
|
It's not forgotten, but heavily delayed 😭 I'm hoping to take a look in the short term, or at least before the year ends. |
|
2ff9870 addresses the minor review feedback which came up during FCP discussions. As it didn't block FCP and the threads appear to have conclusions, I've incorporated those conclusions into the proposal text. Merging otherwise per #3381 (comment) |
|
Like #3930 (comment) , this is blocked on the wider system actually landing in the spec itself. |
| * `answers` - Array of options users can select. Each entry is an object with an `m.text` content | ||
| block, similar to `question`, and an opaque string field `m.id` for use in response events. More | ||
| blocks might be added in the future. Clients should treat each entry similar to how they would an | ||
| `m.message` event. The array is truncated to 20 maximum options. |
There was a problem hiding this comment.
answers is probably intended to be REQUIRED, since the poll is useless otherwise. For the same reason, it MUST NOT be empty. It would be possible to also define a relationship between max_selections and the array length, but I don't see the necessity - instead it leaves the option open for e.g. selecting the same entry multiple times in the future.
| * `answers` - Array of options users can select. Each entry is an object with an `m.text` content | ||
| block, similar to `question`, and an opaque string field `m.id` for use in response events. More |
There was a problem hiding this comment.
In addition to my other comment, it seems reasonable to me to REQUIRE a plain text representation for each answer. This appears also to match the landscape of current implementations.
| * `answers` - Array of options users can select. Each entry is an object with an `m.text` content | ||
| block, similar to `question`, and an opaque string field `m.id` for use in response events. More |
There was a problem hiding this comment.
The m.ids need to be unique (within the answers array) or otherwise define behavior defining dupes.
Rendered
Note: the implementations below are for an earlier draft of this proposal. The latest draft does not technically have any implementations, but is not functionally different from the prior draft. That prior draft, called "v1", is available here.
Element Web Implementation:
Element iOS Implementation:
Further work:
SCT Stuff:
FCP tickyboxes
No MSC checklist.
Status: "BLOCKED" due to requiring Extensible Events to fully land, which (currently) requires a room version.
Next steps: Land extensible events, or merge an MSC which avoids the dependency.