-
-
Notifications
You must be signed in to change notification settings - Fork 270
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
Comments
Eh, almost seems like more hassle than it's worth, at least to me. 🤷♂️ |
But you wouldn't mind if I take care of the hassle, then? :) |
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 😃 |
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. |
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.The text was updated successfully, but these errors were encountered: