- From: Lenny via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Aug 2023 20:51:19 +0000
- To: public-webrtc-logs@w3.org
The suggestion would be a big downgrade to me, let me explain: I consider it good API design that `RTCSctpTransport` is not available prior to being negotiated because it prevents a bunch of irrelevant default values in case it is not negotiated / not used. This is great for static code analysis. If I have unwrapped the `sctp` property, then I a) know that SCTP has been negotiated, and b) consequently all properties inside of it contain meaningful values. If we were to switch this around and make the `sctp` property itself non-nullable, but properties like `maxMessageSize` inside it nullable, then suddenly `maxMessageSize` would be of type `number | null` in TypeScript. That would be super annoying because if SCTP has been negotiated, I **know** that it can't be `null`, yet would still have to handle `null` every time I access the property. With the benefits of the status quo logic in mind, if we have some other property where the information is relevant prior to negotiation, then it does not belong on `RTCSctpTransport` but rather on `RTCPeerConnection`. However, as of now I don't think such a property exists. Not even the SCTP state because we initialise it with `'connecting'` prior and after SCTP negotiation, so there's no additional information to gain. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2899#issuecomment-1696394091 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 August 2023 20:51:21 UTC