Re: higher level APIs (was:

On 12/05/2018 08:58 PM, Michael Tuexen wrote:
>> 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

I for one want the record boundaries.

(speaking on a tangent: I personally believe that when our goal is to
create services that applications can build on top of, defining higher
layer APIs that try to abstract away protocol features is a huge
mistake, one that leads us into making both the protocols and the APIs
we define less useful than they otherwise would be. So I'm currently in
favor of removing the RTC prefix on the Quic API and simply defining it
as an API that lets an application interface to the QUIC protocol -
period, end of story. I have realized through this discussion that there
are people with more than one opinion on this subject.)

Harald

Received on Wednesday, 5 December 2018 20:37:44 UTC