-
Notifications
You must be signed in to change notification settings - Fork 976
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
swarm/behaviour: Replace inject_* with on_event #2867
Conversation
Replace the various `NetworkBehaviour::inject_*` methods with a single `NetworkBehaviour::on_event` method and a `InEvent` `enum`.
swarm/src/behaviour/either.rs
Outdated
fn on_event(&mut self, event: super::InEvent<Self::ConnectionHandler>) { | ||
match self { | ||
Either::Left(a) => a.inject_listener_closed(id, reason), | ||
Either::Right(b) => b.inject_listener_closed(id, reason), | ||
Either::Left(b) => b.on_event(event.map_handler( | ||
|h| h.unwrap_left(), | ||
|h| match h { | ||
Either::Left(h) => h, | ||
Either::Right(_) => unreachable!(), | ||
}, | ||
|e| e.unwrap_left(), | ||
)), | ||
Either::Right(b) => b.on_event(event.map_handler( | ||
|h| h.unwrap_right(), | ||
|h| match h { | ||
Either::Right(h) => h, | ||
Either::Left(_) => unreachable!(), | ||
}, | ||
|e| e.unwrap_right(), | ||
)), |
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.
While not the actual goal of this effort, this is a nice simplification for the Either
and Toggle
NetworkBehaviour
.
In general, I expect this pull request to simplify many of these general purpose NetworkBehaviour
implementations. (Not that we have that many of them.)
Exciting! |
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.
Did a first pass, looks good overall!
Had an idea how we could deprecate more functions.
// Taken from https://github.com/bluss/either. | ||
impl<L, R> IntoEitherHandler<L, R> { |
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.
Do we still need IntoEitherHandler
?
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.
How else would the IntoConnectionHandler::into_handler
methods of the left and right branch be called?
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.
What I was getting at is: Can we replace it with Either
?
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 we discussed this in the past, see #2192 (comment) @thomaseizinger.
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.
You've got much better memory than I do :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.
What do you think about adding a comment about it?
InEvent::ConnectionEstablished { | ||
peer_id: _, | ||
connection_id: _, | ||
endpoint: _, | ||
failed_addresses: _, | ||
other_established: _, | ||
} => {} |
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.
Why match on all of these in here?
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.
To have a compile time error when any of them change, forcing us to revisit each implementation. I guess it is a bit overkill for this one. Let me know if you prefer this to be changed.
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 it is a good idea but I'd prefer if we do that in a more prominent place. For example, we could have a dedicated public_api.rs
in swarm/tests
that concerns itself with such things. I find it a bit odd that this particular impl should take care of that.
Thoughts?
Thanks @thomaseizinger for the helpful review. Mind taking another look? |
Once everyone is happy with the changes in |
We would have to litter the rest of the codebase with |
…ehaviour-on-event
This allows rolling out the whole patch set in a non-breaking way.
63b70fe provides default implementations for Once we remove the deprecated |
Agreed! |
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.
It is nice that we can release this as a non-breaking change.
Couple of questions:
- https://github.com/libp2p/rust-libp2p/pull/2867/files#r965651079 is not yet resolved
- Are we converting all behaviours in this repository to the new APIs?
// TODO: Instead of the type alias THandlerOutEvent the full definition might be more | ||
// intuitive for users outside of libp2p-swarm. |
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.
Yep, esp. because the type alias is not public!
) { | ||
self.on_swarm_event(InEvent::ConnectionClosed { | ||
peer_id: *peer_id, |
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 that we can fix the references here!
@@ -721,3 +850,182 @@ impl Default for CloseConnection { | |||
CloseConnection::All | |||
} | |||
} | |||
|
|||
// TODO: Rename to FromSwarm |
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.
Should we pool the rename together with the release of this change as well?
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.
We could also name it FromTransport
maybe? I am beginning to more and more take on the notion of libp2p-swarm
being a kind of "runtime" that actually doesn't do anything by itself but passes data between other components so in a way, the swarm itself would never produce an event.
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 favor of naming it FromSwarm
. FromTransport
imo could be confusing because its not an event emitted by a transport implementation (e.g. in the relay protocol we do have events that are actually produced by the relay client transport). Also, some events are still caused by the swarm and not the transport, e.g. a DialFailure
because of swarm connection limits.
That being said, I do generally like the conception of swarm being some kind of "runtime".
// Taken from https://github.com/bluss/either. | ||
impl<L, R> IntoEitherHandler<L, R> { |
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.
What do you think about adding a comment about it?
Closing here in favor of #3011. |
Description
Replace the various
NetworkBehaviour::inject_*
methods with a singleNetworkBehaviour::on_event
method and aInEvent
enum
.I want to open this for early feedback before I update the many
NetworkBehaviour
implementations in/protocols
.Links to any relevant issues
Fixes #2832.
Open Questions
Change checklist