Async and streamable data segments

How should components bundle static assets? We have seen several early incantations of this for WebAssembly modules, e.g. emscripten file systems. Many languages have a concept of embedding data, e.g. go embed, so support for this type of use-case will be needed. The question then is if there is a way to make this a component-first interface.

With a component, we need a way to make individual component data (potentially of a nested component) available to running wasm code, or even surfaced via the asset references proposal in JS.

There are a few key properties from the JS asset references proposal that have strong parallels and are worth highlighting:

• Assets are a reference and may be passed as an import to be loaded asynchronously.
• Resolution is deferrable as this can be resource intensive for disk and/or memory.
• References to assets should be relative to a module (in our case component). A sub-component used as a library, e.g. a component that relies on an asset for a complex regex table, should not have access or be able to infer that another asset exists for a component providing an inference interface to a ML model also stored as an asset.

I'm going to quote @lukewagner here since no one says it better. Additional discussion context here:

What I'd like to see here is that we can leverage component model's linking support to build a language-independent tool that can virtualize a WASI filesystem in terms of data sections (and possibly other non-filesystem interfaces, e.g., a blob store interface).

If core modules have data imports and data sections are added to components, then contents of the data sections may be used to bundle static assets. This allows external sections to be implemented as a virtual filesystem for a component.

Use case

Given a component that implements a simple CRUD interface for a very large ML model, as a host I want to be able to validate and compile a component before data segments have been downloaded.

Snip from wasi-nn interface:

// The graph initialization data.
//
// This consists of an array of buffers because implementing backends may encode their graph IR in
// parts (e.g., OpenVINO stores its IR and weights separately).
type graph-builder = list<u8>
type graph-builder-array = list<graph-builder>

load: func(builder: graph-builder-array, encoding: graph-encoding, target: execution-target) -> expected<graph, error>

Rust source for our component might look like:

let xml = fs::async_stream("fixture/model.xml").unwrap();
let weights = fs::async_stream("fixture/model.bin").unwrap();

let graph = unsafe {
  wasi_nn::load(
      &[&xml.into_bytes(), &weights],
      wasi_nn::GRAPH_ENCODING_OPENVINO,
      wasi_nn::EXECUTION_TARGET_CPU,
  )
  .unwrap()
};

Start with the component definitions in design/mvp/Binary.md, then read the linked wasi-nn interface and the JavaScript asset references proposal. The issue needs an agreed design for asynchronous, deferrable asset loading, component-relative references, and validation before data download; no specific implementation file or test is identified.