Re: higher level APIs (was:

On Wed, Dec 5, 2018 at 12:39 PM Harald Alvestrand <harald@alvestrand.no>
wrote:

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

Do you mean removing the RTC prefix on the p2p parts that require ICE as
well?  In my PR to add client/server I already removed the RTC prefix for
pretty much everything except the name "RTCQuicTransport" which really
means "p2p QuicTransport that uses ICE".

By the way, I'm also in favor of a low-level API that lets higher-level
abstraction be built in JS.  That's what we've designed so far.


>
> Harald
>
>
>
>
>