Hi all. I have a proposal that runwasi releases should provide information to those consuming either crates or shims for wasm runtimes. Runwasi was conceived as an approach to integrate webassembly system interface and components into Kubernetes generally while providing a reasonably "transparent" operational and application experience -- and the response has been wonderful.
As we add new runtimes, however, the name runwasi says wasi -- which of course early on was wasi preview 1, though no one has ever prevented anyone from implementing custom functionality, and we didn't have that intention.
However, as we move forward, I think we should provide potential users with information about wasi and component compliance for each runtime/release in the form of a report. I don't think that the project needs to exclude any behavior, but I do think that conveying to those selecting runtime shims should have information about the runtimes, the support they have for current wasi and component standards, and any custom information like enabling or preventing custom functionality.
As both standards continue to be in flight, it sure doesn't seem to me that anyone need to "comply" at any one point, because the runtimes themselves will or will not handle that work. But I do think that we should aim to help users with understanding what wasi the shims currently support.
There are a few compliance tests out there we can use -- and certainly this is a backlog objective. One step after another.
Hi all. I have a proposal that runwasi releases should provide information to those consuming either crates or shims for wasm runtimes. Runwasi was conceived as an approach to integrate webassembly system interface and components into Kubernetes generally while providing a reasonably "transparent" operational and application experience -- and the response has been wonderful.
As we add new runtimes, however, the name runwasi says wasi -- which of course early on was wasi preview 1, though no one has ever prevented anyone from implementing custom functionality, and we didn't have that intention.
However, as we move forward, I think we should provide potential users with information about wasi and component compliance for each runtime/release in the form of a report. I don't think that the project needs to exclude any behavior, but I do think that conveying to those selecting runtime shims should have information about the runtimes, the support they have for current wasi and component standards, and any custom information like enabling or preventing custom functionality.
As both standards continue to be in flight, it sure doesn't seem to me that anyone need to "comply" at any one point, because the runtimes themselves will or will not handle that work. But I do think that we should aim to help users with understanding what
wasi
the shims currently support.There are a few compliance tests out there we can use -- and certainly this is a backlog objective. One step after another.