Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ECO-4952] Start implementing room lifecycle spec #13

Open
wants to merge 1 commit into
base: base-sha/90b9ac142351df378dc3a31696e5d0bcaf26cb66
Choose a base branch
from

Commits on Sep 23, 2024

  1. Start implementing room lifecycle spec

    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 ably-labs#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
      ably-labs#52)
    
    - Lifecycle behaviour relating to “transient disconnect timeouts”
      (created ably-labs#48)
    
    - Lifecycle behaviour that occurs “asynchronously” outside an operation
      (created ably-labs#50)
    
    - CHA-RL1g2, which refers to emitting “discontinuity events” which are a
      concept not yet implemented; this will come in ably-labs#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 ably-labs#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 ably-labs#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 committed Sep 23, 2024
    Configuration menu
    Copy the full SHA
    c70ee44 View commit details
    Browse the repository at this point in the history