Fully self-descriptive metadata types

[emielsebastiaan]

One thing I am missing has to do with the Types one can find in the Metadata.

Some types are (Rust?!) base types such as ‘u32’, ‘bool’ or base structures such as ‘vec’. It is quite clear how to deal with these in an objective manner.

What I am missing has to do with the higher level objects such as T::Balance, ValidatorPrefs, Address, et cetera. The metadata is not self-descriptive enough to ‘know’ the composition of these higher level objects/structures. Hence an outside system (such as a 'generalized substrate explorer' [https://polkascan.io]) would need to ‘hard code’ the composition of such types or structures.

So I suppose what i am suggesting is to extend the metadata with a description of the composition of higher level objects and structures.

PS: discussion with Gavin on Riot hinted that this is non-trivial change and will likely not be picked up before 2020. Hence this issue is for future reference.

[gui1117]

Some update on it, this will be solved by using scale-info https://github.com/paritytech/scale-info so that full type description will be available in the metadata.

Some more advancment detail #7971 (comment)

[emielsebastiaan]

Almost 2.5 years in the making :)

This feature will (hopefully) lower the maintenance burden on the API-layer teams significantly.
The Polkascan team really looks forward to this feature.

[shawntabrizi]

@ascjones How close are we on this?

We have some ideas which may be temporary fix in the meantime if this will take 6-8 more months.

[ascjones]

Not that long for sure, on the home stretch now - maybe 1-2 months depending on how much time I can dedicate to it, and also what we decide to do about where the metadata itself will be stored (discussed in #8370)

What's your specific use case and what did you have in mind? One approach would be for me to manually generate the metadata for your runtime in the new format, which is possible before all my work gets merged into master.

[xlc]

Some patched version Encode/Decode derive that generates the type metadata and print them on with some special build flag will already be useful. At this will allow us easily to maintain the type definition that currently are manually created.

[shawntabrizi]

yes, that was my hack solution too. Create some kind of temporary RPC which will have the types needed for that node to work.

There isnt a specific use case that i am hunting for (other than making the lives of everyone better). We were walking through the backlog, and this was an issue that has been open for like 3 years. So just trying to figure out if we should come up with a temporary solution.

[apopiak]

Let's get that hacky thing going

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[gui1117]

WIP #8615