-
Notifications
You must be signed in to change notification settings - Fork 984
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: Inject events via single method #2832
Comments
NetworkBehaviour::onEvent(&mut self, event: InEvent)
I agree with your concerns. One thing to note is that the extra match will ident all code handling the event by two tabs: one for the To keep things readable, users will likely extract their own functions anyway except for really simple cases which brings us back to square one with more boilerplate except that the users is more in control of which events to handle. Another problem is that users will likely go unnoticed of new events that they should handle. Another option would be if a Unfinished thought: We could have another macro that lets users tag functions as event handlers, thus picking the ones they want to handle and the macro would fill in the remaining ones: #[libp2p::polyfill_unhandled_events]
impl MyBehaviour {
// Macro can detect this by convention or we add a `#[handler]` attribute
fn on_connection_established(&mut self, event: OnConnectionEstablished) -> {}
} This has big downsides too though:
|
If we go with an enum, we could probably also unify |
Thinking about it more, a single |
👍 in general from my side, I am always worried if I am handling all events that I need to, and this would make it a lot easier to guard against the issue. |
Related to the change on |
Cross-referencing implementation of this proposal #2867. |
This is not interesting in itself for stakeholders. Instead it will be tracked with the cross behaviour communication. See also libp2p#2832.
Finishes work first started with #2832
Description
Replace the various
NetworkBehaviour::inject_xxx
methods with a singleNetworkBehaviour::on_event
method and aInEvent
enum
.Example replacing
NetworkBehaviour::inject_connection_established
:Motivation
NetworkBehaviour
trait
definition by providing a default implementation or not. I argue this decision should be made by the user not by libp2p, i.e. I think users should decide whether to exhaustively match on all event handlers, or ignore most through a wildcard match arm. This is especially relevant when introducing new event handlers in the future.NetworkBehaviour
/ConnectionHandler
cross-communication #2680 and swarm/: Support generic connection management through NetworkBehaviour #2828enum
more intuitive than manyinject_xxx
methods.on_event
method helps differentiate the event handling code inNetworkBehaviour
from the non event handling code (new_handler
,addresses_of_peer
andpoll
).What do folks think? Would you be in favor of this change?
Requirements
Open questions
Are you planning to do it yourself in a pull request?
Yes, unless someone else would like to.
The text was updated successfully, but these errors were encountered: