W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2018

Re: [webrtc-pc] WHATWG streams for data channels

From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
Date: Thu, 11 Jan 2018 18:44:01 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-357022559-1515696240-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:58 UTC