Re: [webrtc-pc] No way to observe DataChannel-only transport events in initial negotiation (#2899)

Thanks for the discriminated union example. That's something to consider in future APIs for sure.

Any change this late probably has to be surgical to minimize breakage.

Every design comes with tradeoffs. E.g. if we were to add a `"new"` state distinct from `"connecting"`, it might help, but A) be somewhat redundant with [signalingState](https://w3c.github.io/webrtc-pc/#dom-peerconnection-signaling-state), B) probably cause breakage, and C) still not solve what to put in the "closed" state:

```ts
type RTCSctpTransport =
  | null | {
    state: "new";
    transport: object;
    onstatechange: object;
  } | {
    state: "connecting";
    transport: object;
    maxMessageSize: number;
    onstatechange: object;
  } | {
    state: "connected";
    transport: object;
    maxMessageSize: number;
    maxChannels: number;
    onstatechange: object;
  } | {
    state: "closed";
    transport: object;
    maxMessageSize: number; // present or not?
    maxChannels: number; // present or not?
    onstatechange: object;
  };

interface RTCPeerConnection {
  sctp: RTCSctpTransport;
}
```
Whether maxMessageSize, maxChannels, or both are present in `"closed"` would depend on when it closed.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2899#issuecomment-1714584044 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 11 September 2023 21:10:26 UTC