- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 28 May 2018 09:11:10 +0200
- To: public-webrtc@w3.org
Den 25. mai 2018 01:48, skrev youenn fablet: > > >> On May 23, 2018, at 9:06 AM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote: >> >> Youenn said: >> >> "It would also be interesting in a world where we would use the QUIC API on the web page server QUIC connection." >> >> [BA] By "QUIC API" do you mean the WebRTC-QUIC API? >> https://w3c.github.io/webrtc-quic/ >> >> That API is for peer-to-peer use (e.g. the QuicTransport constructor requires an IceTransport) > > How is it different though? They are all a QUIC connection on which we might want to send either structured data or media data. > I agree that the security model is different, but let’s say we restrict this API to same-origin contexts only (plus maybe an opt-in by the server). > Then, doesn’t it makes sense to allow using the QUIC server connection in the same way you would do for peer-to-peer? > > FWIW, if we define such an API, we should make it as good as possible, and not care about RTP too much, if not at all. > RTP is the protocol in use for WebRTC currently, maybe it should also have its own API. > It is then up to the other APIs (encoder/decoder) that could be used in conjunction with either QUIC or RTP to be designed adequately. I regard the current set of objects in the API that have RTP as part of their name as "an API to RTP". We may be able to abstract some of their properties into classes that can be superclasses of both RTP and some other transports (this is a change that is invisible to all applications except those that actively walk the inheritance tree), but trying to strictly reuse (say) RTPSender would, I think, be a Bad Idea. Harald
Received on Monday, 28 May 2018 07:11:45 UTC