Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use only the client crate for solana-account-decoder #4

Open
buffalojoec opened this issue Apr 3, 2024 · 4 comments
Open

Use only the client crate for solana-account-decoder #4

buffalojoec opened this issue Apr 3, 2024 · 4 comments

Comments

@buffalojoec
Copy link
Contributor

buffalojoec commented Apr 3, 2024

Problem

As reported in anza-xyz/agave#265, the entire config program doesn't need to be used in solana-account-decoder.

In the linked PR, one of the main issues with this dependency relationship is the implicit dependency of solana-account-decoder on solana-program-runtime. This is no longer the case since this program is now BPF.

However, it's a very opportune time to end the pattern of using full program crates as APIs, and instead use their client crates.

cc @kevinheavey

@buffalojoec
Copy link
Contributor Author

Discussion also continued a bit here #1 (comment), where the main point is determining how the necessary functions land in the client.

From @kevinheavey 's list:

  • ConfigKeys, which has field serialized using short_vec, which I believe Kinobi does not support
  • get_config_data, which is a custom helper function using and relies on short_vec via ConfigKeys
  • The ConfigState trait which Kinobi won't generate since I believe it doesn't generate traits
  • create_config_account, a helper function that relies on ConfigKeys (and short_vec) to build an AccountSharedData

@buffalojoec
Copy link
Contributor Author

Sorry for all of the jumping around @kevinheavey, but I wanted to have a designated place to continue this discussion.

If we hoist the instruction builders out of the program crate and into the client, ConfigState can go with them. That just leaves ConfigKeys, which would be generated in the client but needs short_vec support. We can also hoist get_config_data to the client.

@lorisleiva how feasible is it to support short_vec in Kinobi?

@kevinheavey
Copy link

One solution is to not autogenerate the Rust client. You already have all the client code anyone needs in the Agave repo and it just needs to be cut and pasted here

@lorisleiva
Copy link
Member

Hey @buffalojoec, it shouldn't be too difficult tbh. On the spec side, I just need to add the shortU16 format to the NumberTypeNode. Then it's just the matter of updating the Rust and JS renderers such that they use that new piece of information accordingly. For JS that's super easy as codecs are already ready for this. For Rust, that just mean we'll need to add a dependency to the crate that offers short_vec which may be okay client-side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants