- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Jan 2018 18:44:01 +0000
- To: public-webrtc-logs@w3.org
> That is, the most developer-friendly interface is (IMO) dataChannel.writable + dataChannel.readable, i.e. properties that always exist. This sounds like you'd also like to wrap data channels, so handing out the messages (**not** the content) could also be done using the streams API? So, basically you'd have a stream that hands out messages where each message itself is a byte stream? I think this is what @martinthomson mentioned as well and it's a cool idea but I think we should start with using the streams API for the messages' content for now. (Wrapping data channels in such a way would make a neat JS lib, though.) > The issue then becomes figuring out what happens to your existing API when someone acquires a reader or writer from the stream. Good point. This is what I think would be feasible: * Make `.send` and `.createWritableStream` raise an exception as long as there's an existing `WritableStream` instance that's not closed or aborted. * Either make `.binaryType` read-only once the first chunk has been received or make it read-only as long as a `ReadableStream` instance exists for an incoming message. @domenic Maybe you can also comment on @martinthomson's idea regarding the use of fetch Body mixin as I'm not really familiar with it. If answering that would require understanding data channels a little more, send me a mail. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1732#issuecomment-357022559 using your GitHub account
Received on Thursday, 11 January 2018 18:44:03 UTC