Extract peer message handling into separate method. #585
Conversation
|
Concept ACK. Nice refactor! I'd like to see the PR broken into smaller commits. Possibly:
|
|
@arik-so Do you see this as a first step toward custom message passing ? Like adding a trait to PeerHandler, I agree with Jeff, splitting in smaller commits would be better. |
|
I do indeed see it as a first step towards that. I'm currently focusing on some refactors for the modular handshake PR, and will break this one down into smaller pieces after. One of the challenges of breaking this into smaller pieces is that the extraction of message handling into a separate method requires a redeclaration of the macros. But converting the macros into methods doesn't convey the necessity of doing so for the sake of refactoring. |
|
MessageProcessingDecision could also be something much more involved in the medium term future, as there should be a way for non-Rust-languages to pass in lambdas for handling custom inputs through bindings. That in itself presents some challenges due to various environments' issues with C lambdas capturing context, but that's merely a side note here. |
This is a response to splitting lightningdevkit#585 into smaller components. This extraction will permit a future extraction of all message handling into a separate method, and then later even into a separate trait that will be accessible through language bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction will permit a future extraction of all message handling into a separate method, and then later even into a separate trait that will be accessible through language bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction will permit a future extraction of all message handling into a separate method, and then later even into a separate trait that will be accessible through language bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction will permit a future extraction of all message handling into a separate method, and then later even into a separate trait that will be accessible through language bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction should allow the subsequent creation of a trait for all message handling, thereby enabling more flexibility in the state machine, particularly for bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction should allow the subsequent creation of a trait for all message handling, thereby enabling more flexibility in the state machine, particularly for bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction should allow the subsequent creation of a trait for all message handling, thereby enabling more flexibility in the state machine, particularly for bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction should allow the subsequent creation of a trait for all message handling, thereby enabling more flexibility in the state machine, particularly for bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction should allow the subsequent creation of a trait for all message handling, thereby enabling more flexibility in the state machine, particularly for bindings.
|
Before we go too far down this rabbit hole, it would be nice to get a fix for the relay of graph messages, ala TheBlueMatt@2ce646f. I'm worried that this direction is going to make it harder to do eventually and we may have to walk things back, so would be nice to get that incorporated. |
This is a response to splitting lightningdevkit#585 into smaller components. This extraction will permit a future extraction of all message handling into a separate method, and then later even into a separate trait that will be accessible through language bindings.
This is a response to splitting lightningdevkit#585 into smaller components. This extraction should allow the subsequent creation of a trait for all message handling, thereby enabling more flexibility in the state machine, particularly for bindings.
|
This kinda happened in part on accident with the custom message work, and the rest is more actively maintained in #1023. Closing this here as superseded. |
Additionally, convert some handling macros into a method to avoid hidden control flow logic affecting a "parent" scope.