List view
# The Vision Subxt includes code to generate types from metadata. Others have tried to use this code a couple of times for generating Rust types externally to Subxt, and have generally failed; either giving up or forking the code. # The Plan Let's extract the type generation code into a proper crate, give it a proper API and tidy up various internal details so that we can actually maintain and work on it more easily; it's currently quite a difficult area to do anything in.
Overdue by 7 month(s)•Due by December 30, 2024# The Vision The storage APIs provided with Subxt currently have to cater for what both old and new RPCs can do. Once the new RPC methods are stabilised and the legacy backend removed, let's re-work the storage APIs provided by Subxt to properly expose the full power of the new methods.
Overdue by 7 month(s)•Due by December 30, 2024# The Vision Once the `archive_` RPC V2 methods are stabilised, we probably want to have a backend dedicated to interacting with archive nodes, or at least improve the chainHead backend to take archive methods into account to allow access to historic block details. Let's figure out how best to provide these interfaces in Subxt, noting that eg archive methods don't allow submitting transactions etc. This may evolve into a general issue around how to provide access to the different RPC V2 API namespaces in a type safe way.
Overdue by 7 month(s)•Due by December 30, 2024# The Vision Once the new RPCs are stabilised, we want to stabilise and promote a LightClient first interface. # The Plan - Remove feature flags - Better testing of light client interface
Overdue by 7 month(s)•Due by December 30, 2024# The vision Subxt, as a Rust client, is in a unioque position to be able to target embedded devices and things that POlkadot.js/CAPI are unable to reach. We should leverage this as best as possible to allow some subset of Subxts feature set to be used on no_std devices (`alloc` will likely be necessary regardless). I suspect we can: - allow the subxt macro the build no_std friendly code (see `scale-encode` and `scale-decode` for an approach which neatly avoids any dupe `extern crate alloc` issues by importing deps from `subxt`). - support the OfflineClient being `no_std`; that is, anything that doesn't require network access can probably be achieved without std being enabled, eg constructing transactions, accessing constants and metadata etc. # The plan `scale-decode`, `scale-encode` and `scale-bits` are already on the verge of being no_std compatible thanks to anexternal contributor. Let's try to extend this to `scale-value` and then to `subxt` (and any other crates along the way that I have forgotten about).
Overdue by 10 month(s)•Due by September 30, 2024