Should the constructor take http3Only or something more transport agnostic?
ekinnear opened this issue · 9 comments
In 3eb37c8 a long time ago, we appear to have updated to refer to http3Only in the constructor, even though elsewhere we talk about ensuring transports that provide unreliability, etc.
The WebTransport Overview document, in theory, should provide all of the concepts that we'd want to allow developers to request, and if there's something missing we should probably add it there.
Since our general principle was to refer to properties of the transport that we wanted, not any specific underlying protocol, should we clean this up to also follow that same pattern?
The constructor options argument is requireUnreliable, which seems transport agnostic.
It calls the underlying "Initialize WebTransport over HTTP" algorithm, which is not agnostic:
...because it includes a specific step into fetch:
...where this argument is called "http3Only":
This seems like an editorial choice to allow readers to correlate arguments across specs by name and order.
As such, the W3C spec(s) are very much tied to HTTP/3 and HTTP/2 in their specificity right now, even if the API is forward looking. I.e. both fetch and this spec would be expected to update to support e.g. HTTP/4.
@ekinnear would opening an issue on fetch to have a more agnostic argument name than http3Only be useful? Or would renaming it just on our end help?
Hmm, good point. Do we have details on the rationale within fetch for it being called http3Only?
I could see there being an argument that fetch might be transport specific, whereas WebTransport is trying to be transport-agnostic. Not sure it's a particularly strong argument, though, so aligning the terminology used is probably higher priority.
@ekinnear I don't have insight into this, but maybe they haven't thought about it. It couldn't hurt to open an issue with that question.
... whereas WebTransport is trying to be transport-agnostic.
I don't know that W3C's WebTransport is trying to be transport-agnostic. At the end of the day it details implementation through (today's) fetch.
If the goal is to not come back and fix this spec once HTTP/4 or something is added, we could call this notHttp2 perhaps to save us a PR, but I'm not sure that gains us much. I suggest either doing that or closing this.
It seems hard to predict what changes might be needed for a future HTTP version that doesn't yet exist. It could require a small modification to the current specification, or it could require more work. notHttp2 doesn't seem to buy us much, so I'd recommend closing this issue.