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

Move codec to a separate crate #568

Open
nox opened this issue Oct 20, 2021 · 4 comments
Open

Move codec to a separate crate #568

nox opened this issue Oct 20, 2021 · 4 comments

Comments

@nox
Copy link
Contributor

nox commented Oct 20, 2021

If we move the codec stuff (wire format, frames, decoding…) to a separate crate, we don't need to expose an unstable feature and the tests won't need to reach into public-but-hidden methods.

@seanmonstar
Copy link
Member

Eh, almost seems like more hassle than it's worth, at least to me. 🤷‍♂️

@nox
Copy link
Contributor Author

nox commented Oct 21, 2021

But you wouldn't mind if I take care of the hassle, then? :)

@seanmonstar
Copy link
Member

I think there's also a maintenance cost to separating them. Keeping it in-crate allows other internal parts to access private details. Is there another thing that you hope to gain? I'd probably rather suggest, if need be, we see if can make the codec part of the library public. But hopefully for more than helping the test suite 😃

@d4h0
Copy link

d4h0 commented Feb 13, 2022

Would this make it possible to use this separate codec crate to build clients/servers that are not async?

I think, this would be amazing (for example, for building a client/server that sits directly on top of MIO, like mio_httpc (which currently doesn't implement HTTP 2), or when implementing an HTTP 2 client/server for an actor framework like Stakker. This could be interesting for performance reasons).

Or, probably more interesting, to build a blocking client/server (this could be interesting, for example, for security reasons, because sync clients/servers normally would be much simpler to implement and require fewer dependencies, compared to a high-performance async alternative).

Alternatively, maybe exposing the codec stuff and making the async parts a default feature would work 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

No branches or pull requests

3 participants