-
Notifications
You must be signed in to change notification settings - Fork 949
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
#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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question:
-
In the
NetworkBehaviour
doc, 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
autonat
behaviour, 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? 🙏 |
swarm/src/behaviour/either.rs
Outdated
remaining_established, | ||
), | ||
_ => unreachable!(), | ||
Either::Left(b) => b.on_swarm_event(event.map_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.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
I am afraid there is still one larger work item on swarm-derive
. Otherwise this pull request looks good to me.
swarm-derive/src/lib.rs
Outdated
.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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are multiple variants that contain a ConnectionHandler
which can't be cloned.
See #3046.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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