Re: higher level APIs (was:

> On 5. Dec 2018, at 20:38, Lennart Grahl <lennart.grahl@gmail.com> wrote:
> 
> On 05.12.18 01:01, Peter Thatcher wrote:
>> On Tue, Dec 4, 2018 at 1:48 AM Lennart Grahl <lennart.grahl@gmail.com>
>> wrote:
>> 
>>> 
>>> 
>>> On 04.12.18 03:30, Bernard Aboba wrote:
>>>> Justin said:
>>>> 
>>>> 
>>>> "However, if we want to reframe the effort similar to what Youenn
>>> proposes, namely defining a protocol-agnostic NG API, and then considering
>>> QUIC as one substrate on which this API can be implemented (perhaps amongst
>>> others), that might facilitate reaching a consensus here."
>>>> 
>>>> 
>>>> [BA] Two protocol agnostic APIs have previously been discussed in the
>>> WEBRTC WG:
>>>> 
>>>> 
>>>> a. WHATWG Streams.  At the F2F meeting in Stockholm there was some
>>> enthusiasm for use of WHAT WG streams for multiple transports (e.g. SCTP
>>> data channel as well as QUIC).  At TPAC Lyon, Peter made a concrete
>>> proposal for QUIC, and Jan-Ivar discussed steps toward streams support for
>>> the SCTP data channel.  So there is a concrete proposal for a
>>> protocol-agnostic NG API on the table.  However, it's not yet clear whether
>>> WHATWG streams is the best way to address critical issues such as
>>> multi-threading or whether other approaches might offer similar benefits in
>>> a wider set of circumstances.  So one way forward is to continue to
>>> investigate approaches to multi-threading, including data transfer in
>>> workers and WHATWG streams.
>>>> 
>>>> 
>>>> b. RTCDataChannel.  As Peter noted in his presentation at TPAC Lyon, the
>>> original goal was to enable QUIC as a transport for the existing
>>> RTCDataChannel API.  The current draft of WebRTC-QUIC allows RTCDataChannel
>>> (or at least the reliable portion of it) to be built on top of it, assuming
>>> that the data channel protocol for QUIC were to be defined.  However, it's
>>> not clear how much developer enthusiasm there is for exposing QUIC via a
>>> WebSockets/RTCDatachannel API.
>>>> 
>>> 
>>> If the proposed QUIC API migrates to WHATWG streams and the existing
>>> RTCDataChannel API does too (which is what Jan-Ivar and I have started
>>> working on), then I don't see a real need for a unified API. The
>>> transports will always have different functionality. As a developer, one
>>> would only have to swap out the part of the code that constructs the
>>> transport but sending and receiving a stream would be virtually identical.
>>> 
>>> Thus, IMO the cost of creating a high-level abstraction might be higher
>>> than the benefit iff both already support WHATWG streams for
>>> sending/receiving. However, the impact of "stream of streams"
>>> (RTCDataChannel) vs. "stream" (RTCQuic*) would need to be investigated.
>>> 
>> 
>> What I presented at TPAC as "streams of streams" for both SCTP and QUIC.
>> It's the only way to get things offer the main thread, by using something
>> like Transferable Streams.
>> 
>> But there is a difference between SCTP and QUIC here:  SctpTransport could
>> have more than one "stream of streams" (because it has SIDs), while a
>> QuicTransport can only have one, at least right now.  Another way of
>> thinking about it is that an SctpTransport is a "stream of streams of
>> streams":  SctpTransport -> RTCDataChannel -> Message while a QuicTransport
>> is currently a "stream of streams": QuicTransport -> Stream.
> 
> Let's try to attach context every time we talk about "stream". :)
> 
> An SCTP stream (read: data channel) would be a WHATWG stream of WHATWG
> streams of bytes. Or in other words:
> 
> type Message = ReadableStream<Bytes>
> 
> RTCDataChannel+Streams {
>  readable: ReadableStream<Message>
>  writable: WritableStream<Message>
> }
> 
> Whereas a QUIC stream (currently) would be a WHATWG stream of bytes:
> 
> RTCQuicStream {
>  readable: ReadableStream<Bytes>
>  writable: WritableStream<Bytes>
> }
> 
> (I believe this is what you were saying.)
If you want to change the semantics of data channels from being
message oriented to being a byte stream, you can just ignore the
message boundaries.

Not sure what is wanted.

Best regards
Michael
> 
> Cheers
> Lennart
>

Received on Wednesday, 5 December 2018 19:59:23 UTC