New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature]: Make configuration fields in quinn-proto
public
#1301
Comments
Thanks for your interest! We prefer setters over public fields because it's much easier to maintain stability and perform fine-grained error checking that way, since the public API is decoupled from the internal representation. That said, I agree that the status quo is idiosyncratic, since it mixes both approaches. Perhaps we should privatize all fields and introduce setters for the transport and cryptographic configs. Note that you can use |
Yes, this would be awesome! I would like to add that not just new setters are required, but also new constructors. The whole reason why I had to dance around with
Yup, I'm aware that this exists, but doesn't it clone-if-not-unique-ownership? It certainly makes sense now that the internal implementation initializes the What if—in a future version bump—the |
I'm open to this. It's a bit tricky to decide what exactly the constructors should be since we have to balance convenience for the common case against preventing advanced cases from being too awkward, but we're probably not at the sweet spot yet. Modifying e.g.
Yes. Specifically, it replaces the |
Ah, you're right. I have misunderstood the semantics. Reading the source code again, I have found that the
Nice! That's good to hear. Luckily, there are only two constructor arguments here in question: Some crates in the ecosystem follow such a convention, where configuration structs have a default value, then in the constructor, we typically invoke something along the lines of: This is actually why I proposed that we allow construction via public fields. Most users may still invoke the usual constructors. But for advanced configurations, it would certainly be appreciated to at least have the option to tailor the We thereby work around the discussion of "which constructors to expose" because the public fields already enable various permutations of configuration. In case there are certain fields that require additional checking, then it's totally fine to keep them private. Otherwise, I motion for public visibility. |
Note that |
Ah, forgot about that. Just to throw some ideas: we may conditionally implement |
|
That's unfortunate. I suppose the dedicated constructors seem to be the only workable path forward (which I'm also fine with). |
Actually, |
Right... Then that would mean the In practice, the |
I think #1301 would cover this? |
Yup, it almost does. There is one missing feature, though: the For the other fields, however, I'm totally fine with them being left out since they should be relatively cheap to overwrite via the builder methods. This is not the case for |
Alternatively, we may include the |
I don't think it makes sense to go out of the way to avoid building |
That's a fair point. Indeed, the one-time initialization cost shouldn't be too much to bend over backwards for. Stylistically, I would still prefer the direct initialization, but it's not a deal-breaker. |
Though to be clear, I have no objection to adding it to |
That is true. Just to throw an idea, though: what if we use the |
That is already how |
Oh... Hadn't realized. 😅 Well, in any case, I'll put my two cents here in saying that I'd still appreciate introducing the extra argument to |
Revised the PR, please have another look (and leave feedback in the PR's changes rather than here, please). |
Some
Arc
ShenanigansTo initialize a server/client endpoint, Quinn first requires configuration (e.g. via
TransportConfig
,ServerConfig
, etc.). As mentioned in the documentation, the default options are sufficient for most use cases. Otherwise, we have to go through some hoops with setter methods to achieve the behavior we want.I hope the example above demonstrates my nitpicks with the current API. This is exactly what I faced in one of my projects which required a custom protocol (mostly for network efficiency's sake because JSON-over-HTTP is too verbose).
My Proposed Solution
Instead, I propose that all fields of the various
*Config
structs be made public. After all, most of their methods are solely transparent setters. We may as well treat the fields to be public.To accommodate for default values, we simply use the default spread syntax (
..Default::default()
) when initializing from the user code.Here, I demonstrate the fact that we no longer have to jump through the hoops of indirection. In particular, direct initialization allows us to remove the
Arc
shenanigans altogether.This, to me, is a significantly more ergonomic API than using the original setters. Of course, we don't have to remove the setters from the library. Though, I am not totally against deprecation.
I would love to know your thoughts about this API change. I'd love to send in a PR that addresses this. Just wanted to collect some feedback before committing my time.
The text was updated successfully, but these errors were encountered: