Convert component resource to list<u8> - #17
Conversation
Resources are not composable from unique sources within the same component. For example, component resources in the wac-loader could only be consumed as resources from the wac-loader. This makes it impossible to actually bootstrap and compose a component. Switching to a record avoids these issues. A significant downside to using a record is that the bytes for the component must be initialized when the record is created. This makes lazy loading components on demand impossible. Likewise, if we wanted to change the list<u8> to stream<u8>, it could only be read once, and inherently less useful. Signed-off-by: Scott Andrews <scott@andrews.me>
ba17637 to
93c0433
Compare
wit map's are now part of the component model spec. Unfortunately, the
key cannot be a complex type like a record, or even a type alias for a
supported type. So we're denormalizing the id types from records to
strings. Each id take the form of `type:{value}` so that the keys in
each map are unique.
Signed-off-by: Scott Andrews <scott@andrews.me>
Loaders may extract and populate the wit, or leave it empty until a consumer needs the wit content. Signed-off-by: Scott Andrews <scott@andrews.me>
Move wit types back into the wit interface. Signed-off-by: Scott Andrews <scott@andrews.me>
markfisher
left a comment
There was a problem hiding this comment.
A few questions, but the overall direction seems right.
| let package = wit | ||
| .package(ExtractedWit::package_id(decoded.package())) | ||
| .expect("decoded package must exist"); | ||
| async fn extract(component: Component) -> Result<Wit, Error> { |
There was a problem hiding this comment.
This function actually returns WIT for any valid bytes, including a package that has 0..N worlds, right? Maybe the extract func should be explicitly more general than "component". It looks like the Wit type itself already is.
| #[allow(async_fn_in_trait)] | ||
| fn into_wasm(&self) -> Vec<u8> { | ||
| self.wasm.clone() | ||
| Ok(wasm.collect().await) |
There was a problem hiding this comment.
Now that this is effectively a single-line implementation, is having it in a component justifiable? Why wouldn't a consuming component just call collect() itself instead of call this component's function?
There was a problem hiding this comment.
yea, can clean that up when restructuring the loaders
|
|
||
| world wac-loader { | ||
| import componentized:component/types@0.0.0-0; | ||
| export componentized:component/types@0.0.0-0; |
There was a problem hiding this comment.
The explicit types export shouldn't be necessary.
There was a problem hiding this comment.
it is because of the error
| ) -> Result<Component, Error> { | ||
| async fn plug(socket: Component, plugs: Vec<Component>) -> Result<Component, Error> { | ||
| let mut graph = CompositionGraph::new(); | ||
|
|
There was a problem hiding this comment.
Should this component also import a wasm-validator, or are the error messages from wac_graph just as useful?
There was a problem hiding this comment.
I'm not sure if wac validates anything more that the interfaces being combined, plug even less so than graph. We can add explicit validation if it proves useful in the future.
Resources are not composable from unique sources within the same component. For example, component resources in the wac-loader could only be consumed as resources from the wac-loader. This makes it impossible to actually bootstrap and compose a component.
Switching to
list<u8>avoids these issues.