- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Jan 2018 15:07:27 +0000
- To: public-webrtc-logs@w3.org
@aboba I can't see why this wouldn't work with a message size limitation. Once the stream reaches a total size that would go above that limit, the stream could be aborted (which will probably mean the data channel will be closed). Alternatively, an exception could be raised for the writer's `.write` call, so the user is theoretically able to choose what to do (close early or abort the stream, really depends on whether this would break `.pipeTo` - maybe @domenic can comment on that). So, I don't see maximum message size being a blocker here. **But** IIRC, the maximum message size limitation exists because people were concerned about stream monopolisation by large data channel messages. AFAIK, Randell's suggestion of using PPID-based fragmentation/reassembly has not been accepted by other parties and so we ended up with this limitation in the SDP and this bubbled up into this spec. With the SCTP ndata extension, stream monpolisation is not an issue anymore. With this API change, backpressure would not be a concern anymore. So, as far as I'm concerned, `maximumMessageSize` can go (well, it should stay in the API for legacy reasons but just say *infinite*) as it was planned, see [this IETF discussion](https://mailarchive.ietf.org/arch/msg/rtcweb/cJTkaAbgdCTUg4sg97tjCrFVvLo). If there is another reason why we have this, let me know. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1732#issuecomment-360493556 using your GitHub account
Received on Thursday, 25 January 2018 15:07:32 UTC