-
Notifications
You must be signed in to change notification settings - Fork 1k
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
refactor(request-response): revise public API to follow naming convention #3159
Conversation
and RequestResponseHandlerEvent to HandlerEvent.
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.
Nice work! Thanks :)
#[doc(hidden)] | ||
pub enum RequestResponseHandlerEvent<TCodec> | ||
pub enum HandlerEvent<TCodec> |
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.
Would just Event
be pushing it too far? :D
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.
In case it isn't I think the handler
module should be private so this Event
can't clash with the other one.
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.
Intuitively libp2p::request_response::handler::Event
reads better than libp2p::request_response::handler::HandlerEvent
and would be inline with the convention this pull request is enforcing.
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.
yeah makes sense to me, thanks for the suggestion,
So, there is request_response::Event
and request_response::handler::Event
now. Can you expand on Event
's clashing Thomas?
There will still be request_response::RequestResponseHandlerEvent
which is deprecated and suggests request_response::handler::Event
, if we make handler
private how can we export both?
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.
Yeah if we make handler
private, we can no longer export it. What I meant with clashing is that from the outside, there is really only one event that is interesting for users and it is the NetworkBehaviour
's OutEvent
.
Given that we are already making this a breaking change, we might as well make handler
private. In my opinion, no one should be depending on just the ConnectionHandler
.
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.
Thanks for the explanation Thomas. Handler
and Event
can't be private because NetworkBehaviour::ConnectionBehaviour
associated type needs to be public, and by consequence ConnectionHandler
's also
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.
Thanks for the explanation Thomas.
Handler
andEvent
can't be private becauseNetworkBehaviour::ConnectionBehaviour
associated type needs to be public, and by consequenceConnectionHandler
's also
Hmm that is news to me! We have a lot of protocols where the ConnectionHandler
implementation is completely private to the crate. For example ping
:
rust-libp2p/protocols/ping/src/lib.rs
Line 45 in 5755942
mod handler; |
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 just tested it locally and things compile if I make the handler
module private. However, I'd suggest that we don't do this for now. I think together with #3159 (comment), we can make this completely non-breaking?
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.
Thanks for digging this deeper Thomas! Did you understand what is it that with request-response
that was making the compiler complain?
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 think the issue is fairly subtle:
If you have a public type that implements a trait, the compiler enforces that the associated types also need to be public. It does however not check whether the type is within a public or private module in regards to the crate.
In our usecase, this means we can have a pub struct Handler
that implements ConnectionHandler
but define it within a crate-private module handler
. This may or may not be a bug in Rust but I think one can argue that it makes sense:
The API contract promised to the user is that Behaviour
implements NetworkBehaviour
. NetworkBehaviour
enforces that NetworkBehaviour::ConnectionHandler
implements IntoConnectionHandler
. The user can refer to this type as <Behaviour::ConnectionHandler as IntoConnectionHandler>
and call all public APIs on that. They don't need to know the concrete type that implements the functionality. This way, only the minimal promised API is actually exposed.
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.
Other than the comments by Thomas above, this looks good to me.
Thanks @jxs.
#[doc(hidden)] | ||
pub enum RequestResponseHandlerEvent<TCodec> | ||
pub enum HandlerEvent<TCodec> |
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.
Intuitively libp2p::request_response::handler::Event
reads better than libp2p::request_response::handler::HandlerEvent
and would be inline with the convention this pull request is enforcing.
149a2c5
to
eddda25
Compare
eddda25
to
d2880cc
Compare
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.
This is missing a version bump in the root Cargo.toml
, right?
/// protocol family and how they are encoded / decoded on an I/O stream. | ||
#[deprecated( | ||
since = "0.23.0", |
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.
since = "0.23.0", | |
since = "0.24.0", |
#[doc(hidden)] | ||
pub struct RequestResponseHandler<TCodec> | ||
#[deprecated( | ||
since = "0.23.0", |
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.
since = "0.23.0", | |
since = "0.24.0", |
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.
Thanks Max, addressed.
#[doc(hidden)] | ||
pub enum RequestResponseHandlerEvent<TCodec> | ||
#[deprecated( | ||
since = "0.23.0", |
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.
since = "0.23.0", | |
since = "0.24.0", |
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.
Thanks Max, addressed.
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.
Thanks for doing this!
A few minor comments :)
f7e1c43
to
637a32d
Compare
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.
Changes look good to me. No objections to merging other than the missing version change and changelog entry.
@thomaseizinger any remaining comments?
Cargo.toml
Outdated
@@ -106,7 +106,7 @@ libp2p-plaintext = { version = "0.38.0", path = "transports/plaintext", optional | |||
libp2p-pnet = { version = "0.22.2", path = "transports/pnet", optional = true } | |||
libp2p-relay = { version = "0.14.0", path = "protocols/relay", optional = true } | |||
libp2p-rendezvous = { version = "0.11.0", path = "protocols/rendezvous", optional = true } | |||
libp2p-request-response = { version = "0.23.0", path = "protocols/request-response", optional = true } | |||
libp2p-request-response = { version = "0.24.0", path = "protocols/request-response", optional = true } |
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.
Given that this is a breaking change for libp2p
, this pull request needs to bump the libp2p
version to v0.51.0
. Can you please also add a changelog entry to the root CHANGELOG.md
file. See previous entries for reference.
Nope, LGTM! |
Actually, I do want to finish one discussion: #3159 (comment) |
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
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.
Lovely, thanks so much!
I am thrilled that this is backwards-compatible now :)
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
3dc01fe
to
223ec5f
Compare
fixed the merge conflicts, and updated the deprecation message to |
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
Description
Notes
Continues addressing #2217.
Per commit review is suggested :)
Open Questions
Change checklist