BiagioFesta / wtransport

Async-friendly WebTransport implementation in Rust
Apache License 2.0
470 stars 31 forks source link

Rename connection to session? #222

Open MOZGIII opened 2 months ago

MOZGIII commented 2 months ago

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:

The downsides are:

BiagioFesta commented 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.

MOZGIII commented 2 months ago

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.

BiagioFesta commented 2 months ago

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 into Session.

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".

MOZGIII commented 2 months ago

Great, thanks for making it clearer for me!