Stream: git-wasmtime

Topic: wasmtime / Issue #2423 Document guidelines for new WASI p...

Wasmtime GitHub notifications bot (Nov 18 2020 at 16:38):

jedisct1 commented on Issue #2423:

These guidelines look great!

But is the idea to keep full implementations of proposals within the wasmtime tree (as it seems to be the case for wasi-nn), or just wasmtime-specific glue to more generic code that could be shared with other runtimes?

Nobody's using wasi-common beyond wasmtime. This is sad. Each runtime wrote their own implementation instead, even runtimes written in Rust.
Maybe something we don't want to repeat for other proposals; it is not going to scale well as the number of proposals keeps growing. Having full, and wasmtime-specific implementations of WASI proposals here may not be optimal if we want them to get adoption in the WebAssembly world at large.

So, maybe it would be worth clarifying what exactly would be maintained in the wasmtime repository?

Wasmtime GitHub notifications bot (Nov 18 2020 at 17:14):

tschneidereit commented on Issue #2423:

But is the idea to keep full implementations of proposals within the wasmtime tree (as it seems to be the case for wasi-nn), or just wasmtime-specific glue to more generic code that could be shared with other runtimes?

That is the idea, yes. Or at least it's one way to organize things, not the only possible one. But in the interest of full disclosure, I've argued for doing things this way, because I think there's a lot of benefit to it. In particular, we should make it as easy as possible to experiment with proposals, ideally by enabling them by default in the binaries we provide, so content authors don't have to configure and compile their own runtime. That is made significantly harder by keeping the proposals external, to the point that I don't think we should take on that burden.

Maybe something we don't want to repeat for other proposals; it is not going to scale well as the number of proposals keeps growing. Having full, and wasmtime-specific implementations of WASI proposals here may not be optimal if we want them to get adoption in the WebAssembly world at large.

I agree that there's a cost to it, yes. However, there's also a very strong upside, that in my opinion wins out. The standardization process for WebAssembly with good reason requires multiple independent implementations of all features before stabilizing them in the spec. There are multiple reasons for this, and which ones are crucial depends on the nature of the proposal in question. For WASI, I think most of the time the most important one is demonstrating the viability of multiple independent implementations. I know that both in the Wasm context and for JS, this requirement has caught fundamental problems with proposals in the past. And I know that not enforcing it has caused features to be standardized that then turned out not to be implementable. In JS, one of those still exists in the spec and is still shipped by a single vendor.

Wasmtime GitHub notifications bot (Nov 18 2020 at 18:03):

abrown commented on Issue #2423:

content authors don't have to configure and compile their own runtime

I am in favor of @tschneidereit's point of making it really easy for users to test new WASI proposals. And I am also not opposed to having a separate repo for the sake of re-use. In wasi-nn's case, re-use is complicated by 1) the fact that the wasi-nn implementation is highly dependent on wiggle and wasmtime-wiggle, 2) Wasmtime provides wiggle/wasmtime-wiggle yet would depend on wasi-nn (a cycle), and 3) that no one is asking to re-use wasi-nn :big_smile:.

Wasmtime GitHub notifications bot (Nov 20 2020 at 12:22):

tschneidereit commented on Issue #2423:

And I am also not opposed to having a separate repo for the sake of re-use.

To clarify, I most definitely don't want to say that we should somehow actively oppose separate repos and discourage re-use. While there are risks attached to that, ultimately the decisions around those need to be managed by proposal champions, and aren't something we can somehow address in general guidelines on the Wasmtime side.

In wasi-nn's case, re-use is complicated by 1) the fact that the wasi-nn implementation is highly dependent on wiggle and wasmtime-wiggle, 2) Wasmtime provides wiggle/wasmtime-wiggle yet would depend on wasi-nn (a cycle), and 3) that no one is asking to re-use wasi-nn :big_smile:.

This gets more to the heart of the issue :smiling_face:️ If we want to encourage use of our tooling around WASI APIs — which seems highly desirable, because it's good tooling 😛 — then these issues seem to apply, and are quite hard to resolve. Until someone goes and does the probably pretty hard work to get them resolved, I think we should assume them as part of the context, and structure our guidelines accordingly.

Wasmtime GitHub notifications bot (Nov 20 2020 at 17:24):

alexcrichton commented on Issue #2423:

Ok I've pushed up some stronger wording, and RFC requirement, and explicitly stating what's possible depending on the phase of the proposal.

Wasmtime GitHub notifications bot (Nov 20 2020 at 17:24):

alexcrichton edited a comment on Issue #2423:

Ok I've pushed up some stronger wording, and RFC requirement, and explicitly stating what's possible depending on the phase of the proposal. (thanks for the suggestions!)

Last updated: Nov 22 2024 at 16:03 UTC