The message server integration came last minute before the original 0.40.0 rc was cut. This left the IBC code a little bit in a disarray since it integrated the message server without reworking our internals which heavily relied on the previous SDK handler design. We have like 2 layers of redirects right now and structs that are being created and then never used, such as sdk.Result.
This may become problematic since it is hard to understand what each layer is doing here. There should really only be 2 layers, 1 for entry point from the SDK app, the second should be contained in the sub module itself. That is, a create client message, should enter the IBC handler at the top level and then it should go directly to the sub-module message server (02-client/keeper/msg_server.go). The IBC keeper shouldn't house all the message server itself, it doesn't add any benefit.
Summary
The message server integration came last minute before the original 0.40.0 rc was cut. This left the IBC code a little bit in a disarray since it integrated the message server without reworking our internals which heavily relied on the previous SDK handler design. We have like 2 layers of redirects right now and structs that are being created and then never used, such as sdk.Result.
This may become problematic since it is hard to understand what each layer is doing here. There should really only be 2 layers, 1 for entry point from the SDK app, the second should be contained in the sub module itself. That is, a create client message, should enter the IBC handler at the top level and then it should go directly to the sub-module message server (02-client/keeper/msg_server.go). The IBC keeper shouldn't house all the message server itself, it doesn't add any benefit.
For Admin Use