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
Due to the static-typed design of Hermes SDK, we currently hard code the chain type positions, with the StarknetChain always being the first/target chain, and CosmosChain being the second/counterparty chain. The consequence is the commands like query client state can only be called on the Starknet chain, but not on the Cosmos chain.
There are ways to use CGP to generalize the chain types, such as having a StarknetOrCosmosChain wrapper context. However, the current time constraint for the MVP makes it challenging to implement such full generalization without risk of delay.
As an alternative, we would build three separate CLI contexts to support the two positions. The second CLI context would have Cosmos chain as the first chain and Starknet chain as the second chain. The third CLI context would act as a dispatcher, by first determining from the config which chain type is in the first and second position of the CLI.
Note that this approach will require quite a bit of boilerplate to implement the second and third CLI contexts. But we will only able to revisit the code and reunify the commands under a single CLI implementation after the MVP is done.
The text was updated successfully, but these errors were encountered:
Due to the static-typed design of Hermes SDK, we currently hard code the chain type positions, with the
StarknetChain
always being the first/target chain, andCosmosChain
being the second/counterparty chain. The consequence is the commands like query client state can only be called on the Starknet chain, but not on the Cosmos chain.There are ways to use CGP to generalize the chain types, such as having a
StarknetOrCosmosChain
wrapper context. However, the current time constraint for the MVP makes it challenging to implement such full generalization without risk of delay.As an alternative, we would build three separate CLI contexts to support the two positions. The second CLI context would have Cosmos chain as the first chain and Starknet chain as the second chain. The third CLI context would act as a dispatcher, by first determining from the config which chain type is in the first and second position of the CLI.
Note that this approach will require quite a bit of boilerplate to implement the second and third CLI contexts. But we will only able to revisit the code and reunify the commands under a single CLI implementation after the MVP is done.
The text was updated successfully, but these errors were encountered: