# Introduction

[WIT](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md), as it exists today, is a format for describing the **ABI** of *interfaces*; `*.wit` files do not express the direction of the interface (i.e `import` or `export`). It is up to the code generator and language SDKs to specify whether the `*.wit` file is to be interpreted as an interface to be imported or exported.

* Preface: I just want to throw out some new concepts that are actively being discussed in c-m repo. Nothing's final, everything's in flux, but I thought it'd be useful to share more broadly here for feedback and discussion.
* I only have X min of slides here, so happy to interleave discussion

* What does a `wit` currently define? A single "interface"
* Let's take an example interface: http/Handler (show the sketch you have below)
* There are 4 ways currently in wit-bindgen to consume an interface:
* As a host implementing handle called by wasm (presumably it goes and performs a fetch on the internet)
* As a host calling handle (presumably the host is a server and just received a request from the outside)
* As a guest importing handle (so it can issue fetches, like `fetch()` JS code)
* As a guest exporting handle (serverlessly...)
* See how it's just 1 interface but 4 perspectives? {guest,host}x{import,export}
* `wit-bindgen` has ways to express all 4 for various codegen backends
* And that's not the only interface the component will import/export:
* Logging/logger
* `handle` for GRPC
* ...
* In general: a single component will refer to 0..N interfaces in its imports and exports
* Diagram with component in the middle and arrows pointing outward representing imports and exports pointing to interface names (http/Handler, etc)
* For example, a component running in a CLI environment will import interfaces for filesystem, logging, etc, and export a "main" function interface
* I'd like to introduce a new thing we can define in `WIT` called a `world`. It collects the N imports and N exported interfaces of a component into 1 definition.
* So, continuing the previous example, the `world` for that CLI environment could be written as `world { import 'logging' import 'filesystem' export 'main }`
* If you're familiar with the component-model explainer, a `world` is just nice `wit` syntax for a component type, and thus captures the contract between the guest component and host runtime as component subtyping.
* One nice thing is that there are now only 2 perspectives (vs. 4 above) for a `world`: as the host implementing the world and as the guest targetting the world
* And mostly, as a developer, I'll only be done one at a time, so it's sortof implicit in: am I embedding a wasm runtime (using those tools) or compiling wasm (using those tools).
* So a world now gives me basically 1 thing to say, and it implies all the rest (imports vs. exports etc)
* But worlds also solve some concrete problems some of us have been running into with wit-bindgen and multiple interfaces too... let me back up and explain these...

---

# Motivations

## Shared tooling

> Given a World, i'm ready to rock (generate all necessary guest or host code)

## Type sharing and linked bindings

Tooling, such as [wit-bindgen](https://github.com/bytecodealliance/wit-bindgen), generates *host/guest* bindings from `*.wit` files where the direction of the **ABI** is externally specified using the `--import/--export` flags.

For example,

# Generate guest Rust bindings where I am importing a "foo" and exporting a "bar"
wit-bindgen guest rust --import foo --export bar

### Related
---

# Walkthrough

> NOTE: The intent of the following examples are purely illustrative and not declaring or suggesting any convention of how to write `WIT` or use it's tooling.

1. show wit you can write today:

Since several of us are interested in an interoperable HttpProxy, let's consider the modeling of a component that implements a hypothetical **ABI** for "proxying" an `HTTP` request to a backend that also accepts requests.

Specifically, we could say that our proxy's "frontend" and "backend" implement the following interface, using the language of `WIT`:

// http-types.wit

resource request {
    method: func() -> method
    path: func() -> string
    // ...
    body: func() -> list<u8>
    
}

resource response {
    status: func() -> status-code
    body: func() -> result<list<u8>, error>
}

variant method {
    get,
    // ...
    other(string),
}

variant error {
    // ...
}

enum status-code {
    // ...
}

// http-handler.wit

use { request, response, error } from http-types

handle: func(req: request) -> result<response, error>

2. what if i wanted to define all of that in one file. why? testing, ... other reasons. link to issue Alex filed
3. show the same except in one file as proposed in that issue. so now we have `interface { ... }`
4. ok, so given that, adding worlds means adding a new top-level definition that looks like this: `world { ... }`
5. simplified http/Proxy world example

---

# Links

1. [Document Worlds](https://github.com/WebAssembly/component-model/pull/83)
2. [Implement a parser for profile syntax in wit-bindgen](https://github.com/bytecodealliance/wit-bindgen/issues/265)
3. [Reimplement host generators in terms of components](https://github.com/bytecodealliance/wit-bindgen/issues/314)
4. [Component Model](https://github.com/WebAssembly/component-model)
5. [wit-bindgen](https://github.com/bytecodealliance/wit-bindgen)
6. [WIT](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md)