Generate clients

[moul]

1. We can generate RPC clients that will implement Tendermint2 verbs + AddPKG, and Call.
2. We can generate either dynamically or statically per-contract clients. This tool can rely on the Internet to query the existing vm/qfuncs helper.

In conclusion, we can either use 1. and be done, or use 2. to call 1. without worrying about marshalling and enjoy a fully type-safe experience with code completion, etc.

---

When considering the "how" of our approach, it is best to aim for an amino-only solution in order to provide the best features and reduce dependencies. However, we can still offer protobuf files to our users, especially if they are generated from Amino. Alternatively, we can create custom generators to generate intermediary standards, allowing users to reuse existing tools and providing the option for deeper integration and custom solutions.

I'm investigating the possibility of creating a custom r/gnolang/blog client without using codegen with a custom gnokey client available at gnolang/blog#9.

---

cc @ilgooz, what's your opinion and expected future needs?

[moul]

Here are the notes from our previous discussion, summarized:

• Regarding SDKs understanding contracts, we can extend vm/qfuncs or create a new call to generate a rich type. This type can be used by tools to generate SDKs or enhance contract understanding for chain clients (incl. logos: [misc/logos] context & next steps #454) and wallets.
• Possible explorations include:
  • Generating amino.TypeInfo.
  • Utilizing cuelang (cc @tbruyelle).
  • Creating a protobuf definition.
  • Generating go typedef/typedecl.
• This work can be potentially merged with @thehowl's effort on rfc: gno doc command #522.

[tbruyelle]

About cuelang, unfortunately the code generation part hasn't evolved as expected since the last time I used it (a couple of years ago though). It's still a very good langage for data definition and validation, but it still lacks the ability to generate the code from it, it's still marked as TODO in their documentation.

Because of that, it also doesn't expose a service keyword like in protobuf, to define the RPC interface.

In conclusion, I no longer think it's a good fit for our need...