higher level APIs (was:

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.

(And while I said that I'll second Youenn's statement, I guess this is
where my opinion differs.)

Cheers
Lennart

Received on Tuesday, 4 December 2018 09:47:14 UTC