Sylvia: Interoperability Cw <-> Sv

[jawoznia]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
cosmwasm-docs	✅ Ready (Inspect)	Visit Preview	✅ 12 resolved	Jul 25, 2024 11:07am

[hashedone]

Left some comments on vercel

[hashedone]

Better structure than before, but still some comments about wording. Also it is like less information is there. I miss examples - in particular executor and queried usage.

[hashedone]

One comment on vercel. When documenting you need to think on all the usecases, not only the basic ones- in fact our software is more often used for chain-dedicated contracts.

[jawoznia]

Better structure than before, but still some comments about wording. Also it is like less information is there. I miss examples - in particular executor and queried usage.

Those are explained in their own page. This page is linked in the docs.

One comment on vercel. When documenting you need to think on all the usecases, not only the basic ones- in fact our software is more often used for chain-dedicated contracts.

You are right. I missed customs when describing usage of MultiTest

[hashedone]

Those are explained in their own page. This page is linked in the docs.

Ahh, the way you linked them made me think those are links to docs.rs; I didn't even click them, tbh. This is a good separation, but I'll add the additional sentence "Read more about how to use them in dedicated Communication section" (and make "Communication" a separate link to the chapter on its own, leaving both entity links pointing to sections directly).

[hashedone]

I'll accept it (there are 3 more small comments in vercel, no more review required when you consider this). However we miss an important part here - submessages workflow.

You briefly mentioned sending messages, but what about submessages? Sure, you send them the same way just use the add_submessage and add some stuff, but there is more housekeeping about them - in particular reply handling. This is described very briefly in sv::override_entry_point but I don't believe it is solid enough. First of all - there is no link to that in this place, it is too much to "figure out". Second of all - this is a very common case and requires attention. We need to add separate section here about this, that would link to override_entry_point, and it would contain well described minimal example of sending submessage to the remote contract (do not put the remote contract code in the example - it is irrelevant boilerplate, use something well-know like cw20-base or cw4-group), and then handling response (including a simple entry point overwrite). Make sure to explain, that without that, the contract would not well-behave in multitest.

I'll create issue for that so it's done in separate PR.

[jawoznia]

I'll accept it (there are 3 more small comments in vercel, no more review required when you consider this). However we miss an important part here - submessages workflow.

You briefly mentioned sending messages, but what about submessages? Sure, you send them the same way just use the add_submessage and add some stuff, but there is more housekeeping about them - in particular reply handling. This is described very briefly in sv::override_entry_point but I don't believe it is solid enough. First of all - there is no link to that in this place, it is too much to "figure out". Second of all - this is a very common case and requires attention. We need to add separate section here about this, that would link to override_entry_point, and it would contain well described minimal example of sending submessage to the remote contract (do not put the remote contract code in the example - it is irrelevant boilerplate, use something well-know like cw20-base or cw4-group), and then handling response (including a simple entry point overwrite). Make sure to explain, that without that, the contract would not well-behave in multitest.

I'll create issue for that so it's done in separate PR.

Good catch!