Re: higher level APIs (was:

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.)

Cheers
Lennart

Received on Wednesday, 5 December 2018 19:39:52 UTC