search

paritytech / parity-common

Collection of crates used in Parity projects
https://www.paritytech.io/
Apache License 2.0
290 stars 218 forks source link

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

Closed dzmitry-lahoda closed 1 year ago

KiChjang commented 1 year ago

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

dzmitry-lahoda commented 1 year ago

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 commented 1 year ago

Isn't this solved by FRAME metadata already?

dzmitry-lahoda commented 1 year ago

solved what? does parity implements JsonSchema trait?

KiChjang commented 1 year ago

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 commented 1 year ago

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

dzmitry-lahoda commented 1 year ago

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 commented 1 year ago

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

KiChjang commented 1 year ago

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

bkchr commented 1 year ago

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 commented 1 year ago

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.