RFC: product manifests#174
Conversation
|
related issue for historical context: paritytech/dotns#53 |
BigTava
left a comment
BigTava
left a comment
There was a problem hiding this comment.
Looks good. I think it misses a very simple example of everything put together just for demonstration purposes.
|
|
||
| type CommonExecutableFields = { | ||
| $v: 1; | ||
| appVersion: SemVer; // Product-defined SemVer of this executable. |
There was a problem hiding this comment.
This reads confusingly. Does the version only apply to the app? Previously we state each executable is versioned. Suggest rename to just version or executableVersion.
|
|
||
| type WidgetManifest = CommonExecutableFields & { | ||
| kind: 'widget'; | ||
| description?: string; // Optional tagline shown on the widget card. |
There was a problem hiding this comment.
Since we have description already in RootManifest we can name this field differently like tagline.
|
|
||
| ```typescript | ||
| type LocalProductConfig = { | ||
| productName: string; // dotNS base name (e.g. "hackm3.dot"). |
There was a problem hiding this comment.
Shouldn't this be productId. We use <product_id> everywhere else. It might be redundant to have hackme3.dot here since we are fetching the manifest from the dotns label entry hackme3.dot already.
|
|
||
| ## Publisher implementation |
There was a problem hiding this comment.
This section sounds like a recipe for implementations. I don't think we should mix rules with example processes in this RFC. I suggest keeping a short "Publisher requirements" or move this into an "## Appendix A - Reference publisher flow"
|
|
||
| If any assertion fails, treat as a write failure: trigger the snapshot-restore path from Step 7's *Rollback on partial failure*, then abort with a diagnostic. | ||
|
|
||
| ## Host implementation |
There was a problem hiding this comment.
Same comment as above. The RFC concerns a well defined convention for hosts and products to follow. It also evolves independently of hosts implementation or underlying systems. Tomorrow the dotNS contract API could change, Bulletin could be replaced with a different storage solution - none of which should require amending this RFC. I suggest moving this to Appendix B - Reference host implementation.
johnthecat
force-pushed
the
rfc/product-manifest
branch
from
b0fd221 to
8b0e27b
Compare
|
@filvecchiato this RFC is not in truapi repo. |
|
@johnthecat can you please raise RFCs in truapi and not here, otherwise we will have diffs in the api |
porting it over now thanks for flagging |
Do you have the link? |
4 participants
Rendered