You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During a BA Packaging SG meeting earlier this year we discussed adopting support for OCI Annotations Spec-compatible metadata for Wasm Components. The idea is that language-tools like cargo-component can read metadata from e.g. Cargo.toml and encode it as custom sections in Wasm. And then tools like wkg can read those custom sections, and encode them into the OCI images in the correct locations. This makes it so that adding component metadata into registries is something that just happens automatically.
Currently wasm-metadata includes support for something called RegistryMetadata. This is encoded in Wasm binaries as a section named registry-metadata and stored as JSON. In the Packaging SG meeting we decided to deprecate this approach and instead replace it with a custom section per field.
Because we are designing this with the express goal of being compatible with the OCI Annotations Spec, the value encodings must be compatible. We do however have liberty over the names of the custom sections, and we can define the mappings between Wasm and OCI in the Wasm OCI specification.
I'm opening this issue to explain what the current plan for this is before opening up any PRs that implement this. My current plan for this is as follows:
Remove support for RegistryMetadata from wasm modules
Replace RegistryMetadata with dedicated custom sections for components
Add support for any remaining custom sections
Document these sections in wasm-tool-conventions
Document these sections in the Wasm OCI Spec
I hope this all makes sense. Happy to answer questions if anyone has any. Thanks!
Tasks
The following sections would need to be encoded to fully match the OCI Annotations Spec:
I'm actually having some reservations about including created in a custom section. I for one like reproducible builds, and I believe that might run directly counter to it.
It might be fine to include in the final OCI binary if inserted by another tool (e.g. wkg), but maybe we shouldn't create a place to store it in the .wasm binary?
Description
During a BA Packaging SG meeting earlier this year we discussed adopting support for OCI Annotations Spec-compatible metadata for Wasm Components. The idea is that language-tools like
cargo-component
can read metadata from e.g.Cargo.toml
and encode it as custom sections in Wasm. And then tools likewkg
can read those custom sections, and encode them into the OCI images in the correct locations. This makes it so that adding component metadata into registries is something that just happens automatically.Currently
wasm-metadata
includes support for something calledRegistryMetadata
. This is encoded in Wasm binaries as a section namedregistry-metadata
and stored as JSON. In the Packaging SG meeting we decided to deprecate this approach and instead replace it with a custom section per field.Because we are designing this with the express goal of being compatible with the OCI Annotations Spec, the value encodings must be compatible. We do however have liberty over the names of the custom sections, and we can define the mappings between Wasm and OCI in the Wasm OCI specification.
I'm opening this issue to explain what the current plan for this is before opening up any PRs that implement this. My current plan for this is as follows:
RegistryMetadata
from wasm modulesRegistryMetadata
with dedicated custom sections for componentswasm-tool-conventions
I hope this all makes sense. Happy to answer questions if anyone has any. Thanks!
Tasks
The following sections would need to be encoded to fully match the OCI Annotations Spec:
created custom sectionReferences
The text was updated successfully, but these errors were encountered: