Stream: git-wasmtime

Topic: wasmtime / Issue #708 Evolving the API of the `wasmtime` ...


view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2021 at 20:31):

alexcrichton edited Issue #708:

I've been reviewing the wasmtime crate from a Rust API perspective and ended up realizing that there's actually quite a few changes that I would like to make to the crate. I think that these changes are far too large so simply send in a PR, so I wanted to make sure that we had some discussion of this first!

In this issue I hope to lay out a vision for an end-state wasmtime crate and what the API might look like. I'm assuming that we can incrementally reach this end-goal over time and the exact route through which we get here isn't too too important. In any case, I'm curious if others have thoughts on all this!

Some of these items below may warrant their own separate issue as well, but I wanted to make sure that I had this all written down in one location first

High-level changes

Config

Engine

Store

Module

Instance

Global, Table, Memory

These types are only accessed via a reference when fetched through an Instance.

Func

This type I think needs a lot of improvements. I think it's best to separate out these concerns into a separate issue, however. Some high-level unbaked thoughts are:

MemoryType, TableType, GlobalType

ImportType, ExportType

FuncType

Trap

Val

WASI

This is now split off to https://github.com/bytecodealliance/wasmtime/issues/727

Name Resolution

This is now split off to https://github.com/bytecodealliance/wasmtime/issues/727

Instantiation is a bit wonky where you have to line up imports 1:1 with the expected imports of the module. We should explore ideas where we have a more name resolution based mechanism which leverages the module system. Would perhaps make it much easier to slot in WASI or slot in a module. Pretty tricky API though so we'd have to think elsewhere about this.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2021 at 20:31):

alexcrichton edited Issue #708:

I've been reviewing the wasmtime crate from a Rust API perspective and ended up realizing that there's actually quite a few changes that I would like to make to the crate. I think that these changes are far too large so simply send in a PR, so I wanted to make sure that we had some discussion of this first!

In this issue I hope to lay out a vision for an end-state wasmtime crate and what the API might look like. I'm assuming that we can incrementally reach this end-goal over time and the exact route through which we get here isn't too too important. In any case, I'm curious if others have thoughts on all this!

Some of these items below may warrant their own separate issue as well, but I wanted to make sure that I had this all written down in one location first

High-level changes

Config

Engine

Store

Module

Instance

Global, Table, Memory

These types are only accessed via a reference when fetched through an Instance.

Func

This type I think needs a lot of improvements. I think it's best to separate out these concerns into a separate issue, however. Some high-level unbaked thoughts are:

MemoryType, TableType, GlobalType

ImportType, ExportType

FuncType

Trap

Val

WASI

This is now split off to https://github.com/bytecodealliance/wasmtime/issues/727

Name Resolution

This is now split off to https://github.com/bytecodealliance/wasmtime/issues/727

Instantiation is a bit wonky where you have to line up imports 1:1 with the expected imports of the module. We should explore ideas where we have a more name resolution based mechanism which leverages the module system. Would perhaps make it much easier to slot in WASI or slot in a module. Pretty tricky API though so we'd have to think elsewhere about this.


Last updated: Dec 23 2024 at 13:07 UTC