You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The relayer interface has a CreateClients function, but it does not return any identifying information of the clients created. It could return 2 strings, the identifiers of the clients created
Just mentioning this as food for thought, no rush to implement
It'd be useful to have access to this information. I think it is worth considering taking this a step farther though and returning a type which has filled in client identifier information. In ibc-go, our testing package has an endpoint type which contains the identifier information of all the client/connection/channel associated with it. This makes for a clean API since you can call:
and so forth and the identifiers get filled in by the relayer
I'm still getting context around this codebase, so I'm not entirely sure how well this idea gets translated, but I think it'd be immensely useful to have some object similar to this endpoint concept. For IBC design you need sort of three interfaces:
relayer
chain
endpoint
relayers should be responsible for relaying and continuing the flow of initiated IBC actions as well as coordinating larger tasks such as setting up clients/connections/channels. chains should be responsible for actions which only require one side (ie sending a packet) and endpoints should be the way a test writer interacts with certain port/channel pairs. I think it'd be useful if endpoints could initiate IBC flows. Like in relation to this command, I only want to create a client on chainA (I don't care about chainB within the test)
The text was updated successfully, but these errors were encountered:
jonathanpberger
changed the title
CreateClients should return clientID's of the clients createdCreateClients should return clientID's of the clients created
Jul 11, 2024
The relayer interface has a
CreateClients
function, but it does not return any identifying information of the clients created. It could return 2 strings, the identifiers of the clients createdJust mentioning this as food for thought, no rush to implement
It'd be useful to have access to this information. I think it is worth considering taking this a step farther though and returning a type which has filled in client identifier information. In ibc-go, our testing package has an endpoint type which contains the identifier information of all the client/connection/channel associated with it. This makes for a clean API since you can call:
and so forth and the identifiers get filled in by the relayer
I'm still getting context around this codebase, so I'm not entirely sure how well this idea gets translated, but I think it'd be immensely useful to have some object similar to this endpoint concept. For IBC design you need sort of three interfaces:
relayers should be responsible for relaying and continuing the flow of initiated IBC actions as well as coordinating larger tasks such as setting up clients/connections/channels. chains should be responsible for actions which only require one side (ie sending a packet) and endpoints should be the way a test writer interacts with certain port/channel pairs. I think it'd be useful if endpoints could initiate IBC flows. Like in relation to this command, I only want to create a client on chainA (I don't care about chainB within the test)
The text was updated successfully, but these errors were encountered: