- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Sat, 19 May 2018 08:35:46 +0200
- To: Peter Thatcher <pthatcher@google.com>
- Cc: public-webrtc@w3.org
On 19/05/2018 1:14, Peter Thatcher wrote: > It sounds like what you're saying is that in our quest to make > lower-level APIs, you don't want it to go so low that it's a pain in > the neck to use. Which I can completely understand. Finding the > right balance between easy to use and flexible and powerful can be > tricky, and we should keep your viewpoint (the "keep it easy" one) in > mind as we consider the tradeoffs in design. > Yes, that is exactly what I mean. There is a long way between providing lower-level APIs and having to re-implement the rtp stack in js.. > But I think that's mostly orthogonal to QUIC vs. RTP. It is not when if we make the decision on how to implement an use case based on what is easier to implement for QUIC and then apply it to RTP. For example, implementing e2ee on the whole encoded frame before packetization is trivial to the best for QUIC (or DC or WS), but implies that we need to add a new custom payload with an agnostic payload packetization when used in RTP. If it was orthogonal, we would only consider what is easiest for RTP, that is implementing e2ee after packetization. Best regards Sergio
Received on Saturday, 19 May 2018 06:35:38 UTC