swarm/behaviour: Replace inject_* with on_event#3011
Conversation
Replace the various `NetworkBehaviour::inject_*` methods with a single `NetworkBehaviour::on_event` method and a `InEvent` `enum`.
…ehaviour-on-event
…ehaviour-on-event
This allows rolling out the whole patch set in a non-breaking way.
There was a problem hiding this comment.
Question:
-
In the
NetworkBehaviourdoc, someinject_*(now on_*) refer Indicates to the behaviour others informs the behaviour should we have them all on the same wording, for consistency? -
updated the
autonatbehaviour, if that looks ok to you will follow to the other protocols
Consistent wording sounds good to me. Thanks for catching that. I suggest only changing the wording on the new APIs. |
sorry, forgot to ask which one should prevail then |
c3e648e to
510fd5e
Compare
"inform" sounds better to me but I don't have a strong opinion here. |
on on_connection_handler_event
to use new FromSwarm variant structs
on NetworkBehaviour implementation
6390f31 to
b9baeb3
Compare
|
I suggest we merge this together with #3085 to make sure both land in the same release. Objections? |
That would be my preference too! |
|
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
| remaining_established, | ||
| ), | ||
| _ => unreachable!(), | ||
| Either::Left(b) => b.on_swarm_event(event.map_handler( |
There was a problem hiding this comment.
@thomaseizinger comment on #3085 (comment) sparked a thought.
What if b implements the inject_* style methods and not the on_* style methods? In such case, this call would be lost, right?
Unless I am missing something combinators like Either need to call the inject_* style methods until we remove them.
There was a problem hiding this comment.
|
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
mxinden
left a comment
There was a problem hiding this comment.
I am afraid there is still one larger work item on swarm-derive. Otherwise this pull request looks good to me.
| .iter() | ||
| .enumerate() | ||
| .map(|(field_n, field)| match field.ident { | ||
| Some(ref i) => quote! { self.#i.on_swarm_event( |
There was a problem hiding this comment.
swarm-derive will need to delegate to the inject_* methods of the corresponding NetworkBehaviour implementations, right? Otherwise our non-breaking deprecation doesn't work.
There was a problem hiding this comment.
yeah right, thanks for noticing Max, I think I addressed all the cases but ptal.
1a662cb to
f0fd82a
Compare
|
Thanks for the follow-ups. Once the last comments in #3085 (review) are addressed, we can merge both. |
|
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
|
#3085 is all approved. Adding |
`libp2p-swarm-derive` released a breaking change (libp2p#3011) as a patch release `v0.30.2`. This patch: 1. Prepares a new minor release of `libp2p-swarm-derive`. 2. Prepares a patch release for `libp2p-swarm` to use the minor release of `libp2p-swarm-derive`. As a follow up we can yank the `libp2p-swarm-derive` `v0.30.2` release. In addition we might want to release `libp2p-swarm-derive` `v0.30.3` containing all patches but libp2p#3011.
`libp2p-swarm-derive` released a breaking change (#3011) as a patch release `v0.30.2`. This patch: 1. Prepares a new minor release of `libp2p-swarm-derive`. 2. Prepares a patch release for `libp2p-swarm` to use the minor release of `libp2p-swarm-derive`. As a follow up we can yank the `libp2p-swarm-derive` `v0.30.2` release. In addition we might want to release `libp2p-swarm-derive` `v0.30.3` containing all patches but #3011.
|
|
||
| /// Enumeration with the list of the possible events | ||
| /// to pass to [`on_swarm_event`](NetworkBehaviour::on_swarm_event). | ||
| pub enum FromSwarm<'a, Handler: IntoConnectionHandler> { |
There was a problem hiding this comment.
Why isn't there Clone derive? I need to forward this to underlying protocols and it seems like I need to match on all variants just to be able to clone and wrap it back into FromSwarm or am I missing something?
There was a problem hiding this comment.
There are multiple variants that contain a ConnectionHandler which can't be cloned.
See #3046.
There was a problem hiding this comment.
Sometimes it feels like we're going through a lot of painful contortions just to avoid saying Arc.
There was a problem hiding this comment.
Sometimes it feels like we're going through a lot of painful contortions just to avoid saying
Arc.
In this case, we would also have to say try_unwrap: https://doc.rust-lang.org/std/sync/struct.Arc.html#method.try_unwrap
Possible but doesn't feel very clean. I don't particularly like both solutions but I think we are getting one step closer with the new event into making composition easier.
#3099 will help with this too because we are removing a few more mentions of the handler there.
Description
Superseeds #2867.
Links to any relevant issues
Fixes #2832.
Open Questions
Change checklist