-
Notifications
You must be signed in to change notification settings - Fork 204
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
Change module structure. #122
Conversation
3a56280
to
48091cc
Compare
3080779
to
8b62be1
Compare
…processing client requests. The largest benefit is that unit testing becomes easier, e.g. testing that the request processing stops when all request senders are dropped.
Rather than reimplement the same logic. Curiously, this commit isn't a net loss in LOC. Oh well.
Cargo.toml
Outdated
@@ -38,6 +38,7 @@ chrono = "0.3" | |||
env_logger = "0.3" | |||
futures-cpupool = "0.1" | |||
clap = "2.0" | |||
service-fn = { git = "https://github.com/tokio-rs/service-fn" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer we pin to a specific hash if there's no crate. Is that OK or do you still want to track master?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
src/errors.rs
Outdated
@@ -84,7 +80,7 @@ impl<E> From<WireError<E>> for Error<E> { | |||
#[derive(Deserialize, Serialize, Clone, Debug)] | |||
pub enum WireError<E> { | |||
/// Error in serializing the server response or deserializing the client request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this comment still accurate? If so it's confusing that this can be for a failed deserialize of a response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
Previous:
client::{sync, future}
andserver::{sync, future}
Now:
sync::{client, server}
andfuture::{client, server}
The instigation for this is that, when there are separate sync/future versions of
Options
, they'd have to be fully qualified as, e.g.,server::sync::Options
, becausesync::Options
could be client options or server options.But also, I expect users will usually be using all futures or all sync, and this makes that a bit more ergonomic. You can just do
rather than
This is built off of #117 and #121 because I didn't want to end up dealing with a bunch of merge conflicts.
Fixes #66
Fixes #123