- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jan 2018 19:36:20 +0000
- To: public-webrtc-logs@w3.org
The mentioned example for WebSocket has several requirements not applicable to data channels and some problems (which the authors of the streams API couldn't address because the WebSocket API is just how it is): * It requires a reliable and ordered transport and therefore would break partially reliable, unreliable and unordered data channels. * It violates the purpose of a message-oriented protocol and breaks it down to a pure byte stream (well, rather chunk stream) protocol. The point of message-oriented protocols is that no framing mechanism in the upper layer is required. * This is not a byte stream but rather a stream of chunks. Thus, if the sender sends me 64 KiB chunks, the receiver will get 64 KiB chunks. Whereas with byte streams this is up to what either side prefers (and also requires less copying with *BYOB* readers because the underlying implementation can copy directly into that buffer if the reader is fast enough). * (There's no backpressure signal for the sender. Adding this in braces because the data channel API has events for that.) (And yeah, I think the API proposed here would also make sense for WebSocket if feasible.) -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1732#issuecomment-358418156 using your GitHub account
Received on Wednesday, 17 January 2018 19:36:26 UTC