Re: higher level APIs (was:

On Tue, Dec 4, 2018 at 9:27 AM youenn fablet <yfablet@apple.com> wrote:

>
>
> > On Dec 4, 2018, at 1:46 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.
>
> Agreed that this is the first thing to investigate in terms of API design.
>

It's possible to implement a WHATWG stream API on top of the API we've
already defined.  The difference is that doing so would not be compatible
with Transferable Streams (or other mechanism to get off the main thread).
Combining Transferable Streams with the QUIC API is when "native" WHATWG
stream support in the API shows its value.


>
> >>
> >>
> >> 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 it is important to quickly ship support for QUIC in the context of
> WebRTC, a RTCDataChannel API on top of QUIC makes some sense to me.
> To be attractive, that would require other things we discussed in the
> past, like a RTCDataChannel constructor, webrtc-ice...
>

Making an RTCDataChannel API on top of QUIC is the first thing we
investigated.  We found that it would take less time and be more flexible
to give a lower-level API, which is what we did.  So if "quickly ship" is
your goal, I don't think the RTCDataChannel API makes sense.  But we made
sure an RTCDataChannel API can be implemented in a small Javascript library
on top of the lower-level API (or a better API, such as a WHATWG API).