- From: Lenny via GitHub <sysbot+gh@w3.org>
- Date: Sat, 09 Sep 2023 11:08:57 +0000
- To: public-webrtc-logs@w3.org
Sure, the design does not align well with my expectations in the case of `maxChannels` and any other potential property bound to anything beyond the _negotiated_ state, because those are only available in the next state and therefore have to be `null`able.
If I were to spec this API freely, I would have preferred to assign each state its own set of properties and make it more friendly to static analysis as a side effect, e.g. something like the following (TS syntax):
```typescript
type SctpTransportState =
| {
name: 'staged';
}
| {
name: 'negotiated';
maxMessageSize: number;
}
| {
name: 'connected';
maxMessageSize: number;
maxChannels: number;
};
interface SctpTransport {
state: SctpTransportState;
onstatechange: ...;
}
```
Therefore, I guess my view of the design does not align with your/the spec authors view of the design and the result just aligned by accident to some degree.
--
GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2899#issuecomment-1712485870 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 9 September 2023 11:08:59 UTC