Skip to content
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

extract udp socket handling into a separate crate #1178

Closed
dvc94ch opened this issue Aug 16, 2021 · 5 comments · Fixed by #1180
Closed

extract udp socket handling into a separate crate #1178

dvc94ch opened this issue Aug 16, 2021 · 5 comments · Fixed by #1180

Comments

@dvc94ch
Copy link
Contributor

dvc94ch commented Aug 16, 2021

I kind of did that for libp2p-quic here but it might make sense to unify the code bases, as it's probably useful to many people using udp sockets.

@Ralith
Copy link
Collaborator

Ralith commented Aug 16, 2021

It's an interesting idea. There's some possible drawbacks:

  • In the long run, people with different use cases might end up each using only a small subset of the capabilities of such a library, which makes it less appealing.
  • It could make porting to new platforms much more difficult for a given user, if such a port is expected to cover every feature, not just that user's requirements (see e.g. winit's maintenance challenges)

@kpp
Copy link
Contributor

kpp commented Aug 17, 2021

I think such a crate should not be general but specialized for use whithin quinn(-proto).

make porting to new platforms much more difficult for a given user

Extracting or not, such an issue remains. So far it is handled as a fallback module. We can do the same.

@dvc94ch
Copy link
Contributor Author

dvc94ch commented Aug 17, 2021

In the long run, people with different use cases might end up each using only a small subset of the capabilities of such a library, which makes it less appealing.

I assume the concern here is mainly with the maintainance overhead if people start requesting lots of features quinn doesn't use. But we can say no to such feature requests.

@Ralith
Copy link
Collaborator

Ralith commented Aug 18, 2021

If it's explicitly quinn- (or at least QUIC-) specific, and only split out for the benefit of people working with quinn-proto directly for whatever reason, then I don't see any major issues.

@djc
Copy link
Member

djc commented Aug 19, 2021

Sounds okay to me, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants