feat(schema): added json schema to support schema on xcm messages

[dzmitry-lahoda]

No description provided.

[KiChjang]

What is this crate? Why isn't serde good enough? What use case are you encountering?

[dzmitry-lahoda]

The crate allows to make schema for serde structs. Serde does alone does not allow to generate schema(afaik cannot just serde::shema_generate or something from its attributes) nor it cannot specify some schema cases (simplest one is custom serializer). We are to send XCM messages from CosmWasm contracts. In order to have API to call messages need to generate clients, CW clients generates depend on Schemars.

[KiChjang]

Isn't this solved by FRAME metadata already?

[dzmitry-lahoda]

solved what? does parity implements JsonSchema trait?

[KiChjang]

AFAICT this is trying to generate a schema, I looked at what this "schema" really is, and it's essentially metadata, which FRAME metadata already generates. I'm yet to be convinced that this is a change that benefits the entire ecosystem; it seems to me that this is done only to solve a specific problem for a specific use-case.

[dzmitry-lahoda]

@KiChjang by ecosystem you mean "polkadot/substrate/ink" only? kind of not considering any other rust base chain, right?

[dzmitry-lahoda]

it seems to me that this is done only to solve a specific problem for a specific use-case.

what you mean by that? SCALE and SERDE attributes also solve specific problem for specific use case. so you asked problem( use case, singualar) - i gave problem. now you asking problems?

[dzmitry-lahoda]

@ordian who else I can tag to talk or what we have the only option?

[ordian]

I think it's reasonable to add support for it as an additional feature that is disabled by default.

Please merge master to make CI happy.

[KiChjang]

Let's step back a bit: why is this dependency absolutely necessary upstream? Can this not be solved by a newtype pattern?

[bkchr]

Let's step back a bit: why is this dependency absolutely necessary upstream? Can this not be solved by a newtype pattern?

How should a newtype wrapper help for a derive macro? The derive macro then has no access to the inner type and its layout.

[dzmitry-lahoda]

Let's step back a bit: why is this dependency absolutely necessary upstream? Can this not be solved by a newtype pattern?

(polkadotsdk(xcm(common))) is what exists, we needed (cosmwasm(xcm(common))).

if you know how to fix it by """newtype""" """pattern"""" please suggest. i do not know except maintaining forks.

my policy of maintaining fork is to have PR if fork is resonably meregable.