Open MOZGIII opened 2 months ago
I had these thoughts in the past, and kept Connection
at the end because was the simplest name for the concept.
Another consideration is that WebTransport does have concept of "Connection", but it also allows multiple "Session"s within the same connection.
wtransport
does not support multiple sessions yet, and thus connection and session overlap.
It might make sense to be more appropriate and rename what today is called Connection
into Session
. Today the renaming is not urgent, as the do have this overlap, however might also help in the future if we decide to support multiple sessions.
I would argue that the relation between the SessionRequest and Connection is incorrectly modeled, as the connection precedes the session request, but the session is not, and is obtained as a result. Thus, even though they overlap, it is wrong. And this is what I find confusing for the new users.
Simplest name for the concept - perhaps it is, but this was probably a concern for the WebTransport RFC authors as well, and they decided against mixing the concepts like this; this is why I don't understand why at the library level a judgement or decision on this has to even be considered - so I deduced it must just be an inconsistency created as a result of confusion about the clarity of the concepts of the underlying spec. For what it's worth, if there were separate session and connection types, the public API of what we have implemented now would likely 90% to 100% reside in the session type, while connection would expose something entirely different.
So, on the urgency of the matter - if it is indeed an error, then the quicker it is corrected the less of an impact it would have for the future development; fixing the bad model can make wonders to unlock how we think about the code and what ways to evolve it further we see. It is not urgent in the urgency sense, but I'd classify it as a high priority due these concerns. I personally do not need this to be done quick or anything, I just show that there are justifications on why something like this should likely be done sooner than later.
I feel like this message went down a bit rude, as it supposes mistakes were made, so I apologize in advance; these are merely logical deductions based on the observations, and I may be wrong.
I would argue that the relation between the SessionRequest and Connection is incorrectly modeled, as the connection precedes the session request, but the session is not, and is obtained as a result. Thus, even though they overlap, it is wrong.
Perhaps I made some mistake, but I do NOT see where I expressed that, can you please show me?
Instead, quoting my self:
It might make sense to be more appropriate and rename what today is called
Connection
intoSession
.
And that indeed expresses the fact that I DO agree on the fact that Connection
is incorrectly used in the wtransport
library (what we call wtransport::Connection
is actually a WebTransport "Session") . Nothing to argue then, we agree on that point, I guess :)
I only mentioned the reason why (erroneously) I ended up naming wtransport::Connection
like that: people are easy to reason about connection between endpoints (in networking). That's ALSO considering the need of "Session" for WebTransport is due to the fact the standard wants to support multiplexing within a single connection (and thus, the need to give a different name); hence, wtransport
does not support that and this need was, let's say, less strictly.
So, on the urgency of the matter - if it is indeed an error, then the quicker it is corrected the less of an impact it would have for the future development;
I DO agree on that. Errors need to fixed as soon as possible.
What I meant was more something like "it is not a bug" and just a naming convention; "critical" in that sense. Please note: this does NOT mean "won't fix" or "not an issue".
Great, thanks for making it clearer for me!
In the WebTransport spec and corresponding terminology the connections is always called session. I suggest altering the
wtransport
type names to accomodate the type names that are closer to the spec.The benefits of this are:
wtransport
internals/specificswtransport
developers for coming up with type names - as they'll be closer to the mental model of WebTransportThe downsides are: