I begin to work on WASI preview 2 and takes inspir...

# webassembly

[sdeleuze]

I begin to work on WASI preview 2 and takes inspiration of the WIT based interfaces for exposing my WASI preview 1 implementation. I will automate the conversion later and will likely create a specification doc to discuss how WIT translate to Kotlin constructs and the other way around. I will ask my some related question in this thread as I progress.

[sdeleuze]

@bashor @Svyatoslav Kuzmich [JB] Should future like used in https://github.com/WebAssembly/wasi-clocks/blob/main/wasi-clocks.wit.md#expiration translate to Deferred<Unit>, Job or something else?

[sdeleuze]

Formal spec for future is not yet written in https://github.com/WebAssembly/component-model/, I guess it maps to https://doc.rust-lang.org/std/future/trait.Future.html.

[Svyatoslav Kuzmich [JB]]

Do you know if there are any docs of the future or maybe examples of bindings?
From discord discussions it seems that future and stream are likely to be removed from preview 2
It would make sense for high-level APIs to expose it as Deferred<T> , but it could also have some lower-level type to avoid dependency on kotlinx.coroutines. Something like what we have with Promise in JavaScript interop, where you can convert Promise to Deferred and back.

[sdeleuze]

Thanks for your feedback, I will check and let you know.

[sdeleuze]

So far, WebAssembly Component Model translation to Kotlin looks like a smooth process. I am not surprised since Kotlin and Rust share some common idioms. https://github.com/sdeleuze/kowasm/blob/main/wasi/src/wasmMain/kotlin/org/kowasm/wasi/WasiClock.kt

[sdeleuze]

After the feedback from Kotlin side, I will reach the Wasm Component Model group to confirm/refine.

[Svyatoslav Kuzmich [JB]]

Looks good overall! I left some github comments to this commit. Please let me know if this answers open questions, or if you will have more. Anyway, we could start with some initial API design and refine it along the way.

[sdeleuze]

Thanks I will take those feedback in account, perform a step of comparison with what is generated for Rust and ask insights to the Component Model team for the remaining open questions.

[sdeleuze]

I think I saw Chrome is going to ship support for both WasmGC and stringref proposal, and that Dart leverages stringref (I think for now Kotlin/Wasm does not). Could stringref improves Kotlin/Wasm interrop with JavaScript and WIT strings? If part of let say WebAssembly 3.0, would stringref potentially impact with how WebAssembly Component Model deals with strings, or are those 2 independant (implementation detail)?

[Svyatoslav Kuzmich [JB]]

We have experimented with stringref and it does improve performance of JS interop. We plan to use it when it is closer to being standardised.

In think it could improve WIT strings interop, especially if other components would adopt it as their internal representation and engines would optimise cases of UTF-8 <-> UTF-16 conversions.

[Svyatoslav Kuzmich [JB]]

would stringref potentially impact with how WebAssembly Component Model deals with strings, or are those 2 independant (implementation detail)

Mostly an implementation detail, but it would allow a sharing reference to immutable string memory without copy (which is currently always required in a linear memory-based CM ABI).
But even without copy, Wasm engines would need to make sure that stringref is valid unicode string (which is not always the case with WTF-16 strings in Kotlin, JS, etc.) before passing it to other component. Hopefully, this bit of information could be cached in the stringref once computed.
This is based on my assumption that CM would include stringref as a choice for CM canonical ABI, but I haven’t seen any opinions regarding stringref from CM folks yet.

[sdeleuze]

I can ask in the next CM meeting and share their feedback.