What is a World?
Posted on
Worlds have emerged as an important tool for WASI.
Luke Wagner's The Path to Components talk gives a great introduction to Worlds, with the story to how we got here, and the path ahead.
WebAssembly/wasi-kv-store#2 is a PR to the wasi-kv-store showing a concrete example of Worlds, and WebAssembly/component-model#83 is a PR to the component-model spec with a lot of detailed information.
This blog post aims to provide a simple answer to the question: What is a World? I answer this question from my own perspective, as someone who didn't previously know anything about component models.
This post is forward-looking; not all of the pieces described here are usable yet. It's a look at what's coming.
What is a World?
A World is a virtual environment for a component.
This packs a lot of meaning into a few words, so let's unpack!
For a Component
A Wasm component is a deployable unit of software.
An Environment
An environment here is the surroundings that a Wasm component can run in. It contains imports and exports that a component's exports and imports can link to. Wasm components are isolated, so this is the only way they can interact with the outside.
A World is a description of what an environment contains. A component can be built to run in a particular World, and then any environment that implements that World can run it.
That's Virtual
Virtual here means that Worlds aren't tied to concrete implementations.
A database API might be implemented using a remote database in a production environment, and using a local-file database in a testing environment. A logging API might write log messages to a local file, a remote log service a console, or a chat channel.
The implementation of a World may be provided by native host code, by other Wasm components, or a mix of both.
The strong isolation properties of Wasm components means that components can't simply "look around" and see what's happening on the system around them. For example, if a logging API doesn't say where the log output is going, and the World doesn't include filesystem access, the component can't look around and see whether the output is going to a file. The output could go somewhere else entirely, and the component will still work.
Virtualization enables testing with mocked dependencies, adapting components written for one environment to run in another, polyfilling older versions of APIs for backwards compatibility, and more.
Wrap up
A World is a virtual environment for a component.
The WASI Subgroup is expected to define some standard Worlds, which environments may chose to implement, allowing developers to produce components that run in many different environments. Hosts may also chose to define their own bespoke Worlds, either by extending or combining standard Worlds, or by describing new Worlds from scratch.
There's a lot more that can be said about Wasm components and Worlds; check out the links in the intro, and follow me for future explorations!