Thomas Eizinger
Thomas Eizinger
> > Should we retain `DummyBehaviour` and `DummyConnectionHandler` but strip the keep-alive logic from them? > > I think this is a good idea. I'll progress in this direction then!
This is ready for another review @mxinden !
> Can you update the pull request description? Updated. Also added new questions.
> > Should we strip the keep alive functionality from `libp2p-ping` as part of this PR or in a follow-up? > > Shall we follow the two step deprecation path...
> This is ready to merge from my end. Feel free to merge in case you want to keep the naming as is or want that to happen in a...
Changelog and PR description are up to date. This is ready to be merged from my end.
> @thomaseizinger can you take a look at the clippy failure? > > ``` > error: unused import: `NetworkBehaviour` > Error: --> examples/ping.rs:44:21 > | > 44 | use libp2p::swarm::{NetworkBehaviour,...
I did a bit more exploration and we will need to change a few more things to make this possible. Concretely, trying to apply `ReadyUpgrade` (https://github.com/libp2p/rust-libp2p/pull/2855) in as many places...
> That being said, many protocols do much more complicated things within those upgrade traits (looking at you kademlia and relay) and I think it would overall be more consistent...
Some more thoughts/analysis on this: ## Type safety At the moment, the `InboundUpgrade` and `OutboundUpgrade` abstraction provide a form of type-safety. They tie the protocol identifier together with the logic...