General issue with 'cargo' components

[pannous]

This proposal is way too Rust specific and out of scope.

Having a registry for wit components will likely one day become a field of power struggle. I'm not interested in that, so in that sense having a relatively neutral Rust-like registry mechanism could be beneficial. On the other hand the word cargo and the Cargo.toml format are way too specific. Adding cargo like semantics to s-exp formatted wit would be aesthetically much more fitting.

[peterhuene]

Hi @pannous. Thanks for the comments!

I think there might be a slight misunderstanding of what cargo-component is and how it relates to otherwise language-agnostic component registries going forward.

cargo-component is simply a cargo extension for building WebAssembly components in Rust. It integrates a wit-bindgen-rust implementation to generate Rust bindings for consuming other WebAssembly components and interfaces. We expect cargo-component to be one of many language-specific tools for authoring WebAssembly components.

While today cargo-component only supports local wit documents for implementing a component in Rust, very soon it will have support for building with dependencies coming from a WebAssembly component registry.

Component registries themselves are language-agnostic and are only concerned with the publishing, retrieval, and verification of WebAssembly components implemented in any language. It is our express desire to make component registries and the component model itself work with as many programming languages as possible and we expect tooling for doing that to be implemented by anyone interested in doing so, within and without the Bytecode Alliance.

There are two repositories that relate to ongoing efforts around the design and implementation of a WebAssembly component registry: SIG Registries repo and the registry implementation repo. Please feel free to look those over, but keep in mind the implementation is very early and changing rapidly.

With this context in mind, is there anything particular to the design or implementation of cargo-component that you see as an issue that needs addressing?

[peterhuene]

Hi @pannous. I'm going to close this issue for now. If you have any additional feedback, please feel free to reopen it. Thanks!