chat: room lifecycle specification

[AndyTWF]

• Adds chat room lifecycle feature specification.
• Also adds feature specs for presence, messages and room reactions

[lawrence-forooghian]

I’ve started implementing this spec in the Swift SDK. In order to be sure that this spec is sufficiently detailed and unambigious, I’ve made the deliberate decision not to consult the JS implementation. I’ll post feedback here as it comes up 🙂

[umair-ably]

@AndyTWF can this be extended to include Typing Indicators please?

I expect to get to this a week today if that's okay? 🙏

[sacOO7]

Hi @AndyTWF, general question, We mutex lock/ priority queue executor in chat-js, which seems imp. part of room lifecycle. It runs internal/external operations based on priority of execution

enum LifecycleOperationPrecedence {
  Internal = 0,
  Release = 1,
  AttachOrDetach = 2,
}

I am not sure why it's not mentioned in the chat spec

[lawrence-forooghian]

@splindsay-92 I’ve pushed a commit to revert 6118c4646a0c68d70c600f81060439bfdd030dbe’s rename of CHA-M3e — please could we avoid renaming spec points where possible, because we already have SDK implementations referring to these points?

[lawrence-forooghian]

Heads-up for those consuming this spec; I’ve updated the duplicate-finding script so that it works for Chat too, and I’ve renamed the following spec points:

Now CHA-RL1j:

** @(CHA-RL1h)@ If the room is in the @INITIALIZING@ status, then it must wait for the in-progress @RELEASING@ operation from a previous room instance to complete before proceeding.

Now CHA-RL3l:

** @(CHA-RL3c)@ @[Testable]@ When the release operation commences, the room will transition into the @RELEASING@ status any any transient disconnect timeouts shall be cleared.

Now CHA-RL3j:

** @(CHA-RL3i)@ @[Testable]@ If the room is in the @INITIALIZED@ status, then the room is immediately transitioned to @RELEASED@ and the operation succeeds.

Now CHA-RL3k:

** @(CHA-RL3i)@ @[Testable]@ If a room lifecycle operation is already in progress, this operation shall wait until the current operation completes before continuing, subject to @CHA-RL7@.

Now CHA-RL4b10:

*** @(CHA-RL4b7)@ @[Testable]@ If a channel lifecycle operation is not in progress and the channel state is @ATTACHED@ and a transient disconnect timeout exists for the contributor, the timeout is cleared.

Now CHA-M5k:

** @(CHA-M5d)@ @[Testable]@ Incoming realtime events that are malformed (unknown field should be ignored) shall not be emitted to subscribers.

Now CHA-PR3c2:

*** @(CHA-PR3c1)@ @[Testable]@ If the attach has not been called, then the @enter@ call will throw an error.

Now CHA-PR10c2:

*** @(CHA-PR10c1)@ @[Testable]@ If the attach has not been called, then the @update@ call will throw an error.

Now CHA-PR6b2:

*** @(CHA-PR6b1)@ @[Testable]@ If the attach has not been called, then the @get@ call will throw an error.

Now CHA-PR7c:

** @(CHA-PR7b)@ @[Testable]@ A subscription to presence may be removed, after which it shall receive no further events.

Now CHA-T2b2:

*** @(CHA-T2b1)@ @[Testable]@ If the attach has not been called, then the @get@ call will throw an error.

[lawrence-forooghian]

@splindsay-92 I’ve pushed a commit to revert 6118c46’s rename of CHA-M3e — please could we avoid renaming spec points where possible, because we already have SDK implementations referring to these points?

@splindsay-92 I’ve also restored the spec point IDs for the ones you deleted — see justification in 9d8cb4396c1bb71e490ed3904b8ba92f5a50c917. Please could you take a look at the guidance for modifying the spec? I think that until recently in this PR we've been pretty lax about it, because nobody had actually implemented this spec, but now that we're further into implementation on Swift and Kotlin I think we should make sure we follow it unless we’re sure that nobody has implemented the spec points we're modifying.

[splindsay-92]

@splindsay-92 I’ve pushed a commit to revert 6118c4646a0c68d70c600f81060439bfdd030dbe’s rename of CHA-M3e — please could we avoid renaming spec points where possible, because we already have SDK implementations referring to these points?

Ah, my apologies @lawrence-forooghian ! I should have double checked this, I'll correct it tomorrow, but thanks for reverting it and letting me know.

[lawrence-forooghian]

@splindsay-92 I’ve pushed a commit to revert 6118c46’s rename of CHA-M3e — please could we avoid renaming spec points where possible, because we already have SDK implementations referring to these points?

Ah, my apologies @lawrence-forooghian ! I should have double checked this, I'll correct it tomorrow, but thanks for reverting it and letting me know.

No worries! Sorry, by "reverted" I meant that I’ve already corrected it

[lawrence-forooghian]

I’ve pushed a couple of updates:

• marked CHA-RL1d1 as testable
• added CHA-GP2a to require that implicit attach be disabled when fetching channels

[lawrence-forooghian]

@AndyTWF I pushed a commit to restore the spec point ID of deleted CHA-RL1h1 (justification as in https://github.com/ably/specification/pull/200#issuecomment-2448171793)

[AndyTWF]

Merging this PR as it's getting a bit large now - please raise any further / outstanding issues in a Chat JIRA issue and post them on our Slack channel! Thanks :)