Merge QuicTransport and Http3Transport into a single class?

[vasilvv]

Currently we have two separate constructors for QuicTransport and Http3Transport:

let transport1 = new QuicTransport("quic-transport://example.org/endpoint");
let transport2 = new Http3Transport("https://example.org/endpoint");

Notice that the transport information is redundantly encoded twice: once in the class name, and once in the scheme.

I propose that we merge those into a single constructor that dispatches based on the scheme:

let transport1 = new WebTransport("quic-transport://example.org/endpoint");  // QuicTransport 
let transport2 = new WebTransport("https://example.org/endpoint");  // Http{2,3}Transport

This has a nice property of increasing transport agility (since URLs are typically data, transport can be changed with no code changes involved), and will probably simplify client implementation too (by reducing code duplication).

[ghost]

How might protocol agility and support be managed? Without a 1:1 mapping of class to protocol, should this change also include a static method that can expose which schemes are available for a given implementation?

[yutakahirano]

What will the relationship between WebTransport and RTCQuicTransport be?

[vasilvv]

What will the relationship between WebTransport and RTCQuicTransport be?

I expect RTCQuicTransport to implement the same set of mixins, but have different class, since any RTC version would be unlikely to be constructible from a URL.

How might protocol agility and support be managed? Without a 1:1 mapping of class to protocol, should this change also include a static method that can expose which schemes are available for a given implementation?

A static method is an option, though since various transports can be made unavailable for various reasons (lack of support in browser, enterprise policy, network firewall, etc), I believe the best approach would be trying to connect to a given URL to see what happens. To quote TAG design principles:

It should generally be indistinguishable why a feature is unavailable, so that feature detection code written for one case of unavailability (e.g., the feature not being implemented yet in some browsers) also works in other cases (e.g., a library being used in a non-secure context when the feature is limited to secure contexts).

[ricea]

What should getStats() do if the transport is not QUIC?

[aboba]

@yutakahirano I assume that RTCQuicTransport will inherit from WebTransport instead of from QuicTransport: https://w3c.github.io/webrtc-quic/#rtcquic-transport*

However, because there is no URI in the constructor I'm assuming that only the QuicTransport protocol would be supported with RTCQuicTransport.

[Tiedye]

Having the additional agility of this scheme seems nice. Though I think the dynamically dispatching constructor is an unusual pattern that isn't really seen in other API's. Maybe a (static) method like document.createElement would be more appropriate to not violate developers expectations of creating objects with new.