Integrate room lifecycle manager with the rest of the SDK #47
Assignees
Labels
enhancement
New feature or improved functionality.
room-lifecycle
Related to room lifecycle (temporary label).
Comments
lawrence-forooghian
added a commit
that referenced
this issue
Sep 18, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 18, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 18, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 19, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 19, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
This was referenced Sep 20, 2024
lawrence-forooghian
added a commit
that referenced
this issue
Sep 23, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 23, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 23, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
This was referenced Sep 26, 2024
lawrence-forooghian
added a commit
that referenced
this issue
Sep 30, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 30, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 30, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 30, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 30, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Sep 30, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Oct 1, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added a commit
that referenced
this issue
Oct 1, 2024
This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
lawrence-forooghian
added
the
room-lifecycle
lawrence-forooghian
added a commit
that referenced
this issue
Nov 7, 2024
The room needs to have access to its contributing channels so that, when do we integrate the RoomLifecycleManager into the SDK in #47, it can use them to create a RoomLifecycleManager instance. So, let’s make the room fetch the channels and then pass them to the features. This way, we only fetch each channel once. Also, in an upcoming commit it will be the room who releases the channels when `release()` is called on it, giving another reason why it makes sense for the room to fetch the channels, I think.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 10, 2024
The room needs to have access to its contributing channels so that, when do we integrate the RoomLifecycleManager into the SDK in #47, it can use them to create a RoomLifecycleManager instance. So, let’s make the room fetch the channels and then pass them to the features. This way, we only fetch each channel once. Also, in an upcoming commit it will be the room who releases the channels when `release()` is called on it, giving another reason why it makes sense for the room to fetch the channels, I think.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 10, 2024
Preparation for integrating the manager into the SDK in #47, in which we’ll want to be able to mock a room’s lifecycle manager. Will fill in the protocol’s methods as needed later.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 10, 2024
Replace the existing temporary implementations of room attach / detach / status with those provided by the room lifecycle manager. Part of #47.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 10, 2024
Replace the existing temporary implementations of room attach / detach / status with those provided by the room lifecycle manager. Part of #47.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
Based on [1] at d9af7bf. I’m assuming that the “no call” in this spec point is a typo and means “a call”; have asked in [2]. Needed for when we integrate the room lifecycle manager into the rest of the SDK in #47 (else there will be a crash when running the integration tests, because a channel’s first ATTACHED status change has resumed == false and our precondition will fail). [1] ably/specification#200 [2] ably/specification#200 (comment)
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
The room needs to have access to its contributing channels so that, when we integrate the RoomLifecycleManager into the SDK in #47, it can use them to create a RoomLifecycleManager instance. So, let’s make the room fetch the channels and then pass them to the features. This way, we only fetch each channel once. Also, in an upcoming commit it will be the room who releases the channels when `release()` is called on it, giving another reason why it makes sense for the room to fetch the channels, I think.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
Preparation for integrating the manager into the SDK in #47, in which we’ll want to be able to mock a room’s lifecycle manager. Will fill in the protocol’s methods as needed later.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
Based on [1] at d9af7bf. I’m assuming that the “no call” in this spec point is a typo and means “a call”; have asked in [2]. Needed for when we integrate the room lifecycle manager into the rest of the SDK in #47 (else there will be a crash when running the integration tests, because a channel’s first ATTACHED status change has resumed == false and our precondition will fail). [1] ably/specification#200 [2] ably/specification#200 (comment)
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
Replace the existing temporary implementations of room attach / detach / status with those provided by the room lifecycle manager. Part of #47.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
Replace the existing temporary implementations of room attach / detach / status with those provided by the room lifecycle manager. Part of #47.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
Replace the existing temporary implementations of room attach / detach / status with those provided by the room lifecycle manager. Part of #47.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
Replace the existing temporary implementations of room attach / detach / status with those provided by the room lifecycle manager. Part of #47.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 11, 2024
Replace the existing temporary implementations of room attach / detach / status with those provided by the room lifecycle manager. Part of #47.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 12, 2024
We use the implementation of the RELEASE operation provided by the room lifecycle manager, and implement the spec points relating to room map bookkeeping and releasing the underlying realtime channels. Based on [1] at 6f0740a. I have not implemented the spec points that relate to making sure that a room fetch waits for any previous room with the same ID to finish releasing; this is a part of the spec which is in flux (currently implemented via the INITIALIZING status, which was added to the spec after we started implementing the room lifecycle manager and hasn’t been implemented in this SDK yet, and soon to be further changed in the spec by making room-getting async). We can look at the current state of things when we come to do #66. Part of #47. [1] ably/specification#200
lawrence-forooghian
added a commit
that referenced
this issue
Nov 12, 2024
We use the implementation of the RELEASE operation provided by the room lifecycle manager, and implement the spec points relating to room map bookkeeping and releasing the underlying realtime channels. Based on [1] at 6f0740a. I have not implemented the spec points that relate to making sure that a room fetch waits for any previous room with the same ID to finish releasing; this is a part of the spec which is in flux (currently implemented via the INITIALIZING status, which was added to the spec after we started implementing the room lifecycle manager and hasn’t been implemented in this SDK yet, and soon to be further changed in the spec by making room-getting async). We can look at the current state of things when we come to do #66. Part of #47. [1] ably/specification#200
lawrence-forooghian
added a commit
that referenced
this issue
Nov 12, 2024
We use the implementation of the RELEASE operation provided by the room lifecycle manager, and implement the spec points relating to room map bookkeeping and releasing the underlying realtime channels. Based on [1] at 6f0740a. I have not implemented the spec points that relate to making sure that a room fetch waits for any previous room with the same ID to finish releasing; this is a part of the spec which is in flux (currently implemented via the INITIALIZING status, which was added to the spec after we started implementing the room lifecycle manager and hasn’t been implemented in this SDK yet, and soon to be further changed in the spec by making room-getting async). We can look at the current state of things when we come to do #66. Part of #47. [1] ably/specification#200
lawrence-forooghian
added a commit
that referenced
this issue
Nov 12, 2024
TODO test TODO test figure out internal interface TODO see if there are any spec points to do TODO if Umair merges reactions before this, we need to incorporate here. Resolves #47.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Split from #28.
This means:
Room, or in the case ofRELEASE,Rooms)RoomLifecycleContributorChannelprotocolRELEASEoperation, and CHA-RL1d, which says to discard the room instance┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: