chat: room lifecycle specification #200
Conversation
AndyTWF
commented
Aug 5, 2024
•
AndyTWF
commented
- Adds chat room lifecycle feature specification.
- Also adds feature specs for presence, messages and room reactions
AndyTWF
force-pushed
the
chat-lifecycle
branch
from
8c569ea
to
aa7455d
Compare
|
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 🙂 |
| ** @(CHA-RS1h)@ The @RELEASING@ status means that the room is being released and the underlying resources are being cleaned up. | ||
| ** @(CHA-RS1i)@ The @RELEASED@ status means that the room has been cleaned up and the object can no longer be used. | ||
| * @(CHA-RS2)@ A room must expose its current status. | ||
| ** @(CHA-RS2a)@ @[Testable]@ A room must expose its current status, a single value from the list provided above. |
There was a problem hiding this comment.
Was it a conscious decision to not describe the API of the SDK in terms of signatures / types (e.g. the way that we do in the main spec, which also has the IDL)?
There was a problem hiding this comment.
The IDL we have for the core SDKs is quite java-centric and in that sense may not be the most idiomatic approach for other ecosystems, so I tried to write the spec in a way that describes the intended interactions and behaviour, rather than prescribe an exact implementation.
Is it worth a note somewhere in the spec to treat the JS implementation as a reference implementation and explain the intention?
There was a problem hiding this comment.
I believe having IDL for chat-SDK will be super helpful.
Almost all of the languages these days are encouraging use of types.
So, having language-agnostic types will surely help.
This is based on [1] at aa7455d. It’s generated some questions, which I’ve asked on that PR. I started implementing this as part of #19, before realising that implementing the spec is not the aim of that task. So, putting this work on hold until we pick it up again in #28. So far, only the ATTACH operation is implemented. Note that I've had to make RoomLifecycle.{ current, error } async, this seems odd but not sure there's a better way if we want to make use of Swift's built-in concurrency. Also it highlights to callers that in a multi-threaded environment there can't be a definitive concept of 'current' which was indeed a concern I'd highlighted earlier. But might revisit this approach and make them synchronous (with some other locking mechanism) insetad. Also had to make `onChange` async so that I could do some state management, that seems weirder and I don’t like it. Things where testing framework makes things messy with concurrency: - `async let` with things like XCTUnwrap, XCAssertEqual - async operations with XCTAssertThrowsError I hope that once Xcode 16 is released we can instead use Swift Testing. [1] ably/specification#200
My editor keep removing this for me (not quite sure why), so just let it.
AndyTWF
force-pushed
the
chat-lifecycle
branch
from
8ebed8d
to
3b576d3
Compare
|
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 :) |
Squashed commits: [234cc2e] Add and improve logging for Messages and Reactions [6697e1e] Spec complete for Presence in line with [1]. [1] - ably/specification#200
