Skip to content
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/src: Remove ConnectionHandler #2519

Merged
merged 2 commits into from
Feb 16, 2022

Conversation

mxinden
Copy link
Member

@mxinden mxinden commented Feb 15, 2022

The ConnectionHandler trait is not exposed to users. The only
implementor of ConnectionHandler is NodeHandlerWrapper. Thus
ConnectionHandler is a superfluous abstraction. This commit removes
ConnectionHandler.

Next to this large change, this commit removes the Tmuxer trait
parameter. Swarm enforces dynamic dispatching via StreamMuxerBox
anyways, thus the trait parameter is useless.

As a follow up to this commit one could rename ProtocolsHandler to
ConnectionHandler and NodeHandlerWrapper to
ConnectionHandlerWrapper or just Wrapper.

Follow up to #2492.

The `ConnectionHandler` trait is not exposed to users. The only
implementor of `ConnectionHandler` is `NodeHandlerWrapper`. Thus
`ConnectionHandler` is a superfluous abstraction. This commit removes
`ConnectionHandler`.

Next to this large change, this commit removes the `Tmuxer` trait
parameter. `Swarm` enforces dynamic dispatching via `StreamMuxerBox`
anyways, thus the trait parameter is useless.

As a follow up to this commit one could rename `ProtocolsHandler` to
`ConnectionHandler` and `NodeHandlerWrapper` to
`ConnectionHandlerWrapper` or just `Wrapper`.
Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! I love how the layers are disappearing :)

/// Handler that processes substreams.
handler: THandler,
handler: NodeHandlerWrapper<THandler>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we inline this struct into Connection now? Then we could just get rid of NodeHandlerWrapper completely!

I think the only reason we are passing this around at the moment is because we are constructing it "too early". We could just pass THandler around everywhere have all other fields of NodeHandlerWrapper be in Connection.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the only reason we are passing this around at the moment is because we are constructing it "too early".

I think you are confusing the concept of IntoProtocolsHandler -> ProtocolsHandler, NodeHandlerWrapperBuilder -> NodeHandlerWrapper and now obsolete IntoConnectionHandler -> ConnectionHandler with the relation between ProtocolsHandler and NodeHandlerWrapper, right?

(Puuuh, so many XXXHandler. I hope we end up with only ProtocolsHandler (renamed to ConnectionHandler) once all the refactorings are in.)

Could we inline this struct into Connection now?

I think so. At least move the two closer together. I suggest we rename ProtocolsHandler to ConnectionHandler first ( including some smaller clean-ups) and then consider folding NodeHandlerWrapper into Connection.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may confuse some things yes 😁

Either order is fine with me, it was a more general remark, not suggesting it should be done next or at all! :)

@mxinden
Copy link
Member Author

mxinden commented Feb 15, 2022

I love how the layers are disappearing :)

Same here :)

@mxinden mxinden merged commit 8ffa84e into libp2p:master Feb 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants