ticket: plan plugin component model migration
This commit is contained in:
parent
3b026b2f5f
commit
e5126321ad
83
.yoi/objectives/00001KVG0HR9M/item.md
Normal file
83
.yoi/objectives/00001KVG0HR9M/item.md
Normal file
|
|
@ -0,0 +1,83 @@
|
||||||
|
---
|
||||||
|
title: "Plugin Component Model migration"
|
||||||
|
state: "active"
|
||||||
|
created_at: "2026-06-19T13:18:58Z"
|
||||||
|
updated_at: "2026-06-19T13:18:58Z"
|
||||||
|
linked_tickets: ["00001KV5W3PHW", "00001KVFDX9AF", "00001KVFDX9AY", "00001KVFD3YSV", "00001KVG0HR96"]
|
||||||
|
---
|
||||||
|
|
||||||
|
## Goal
|
||||||
|
|
||||||
|
Move Yoi Plugin Tool authoring and runtime from the current raw core-Wasm ABI toward the WebAssembly Component Model so Plugin authors can implement typed interfaces rather than hand-writing pointer/length memory plumbing.
|
||||||
|
|
||||||
|
The target is not to weaken sandboxing or Plugin grants. The target is to make Plugin ABI, host APIs, SDK bindings, and future multi-language authoring use typed WIT worlds while preserving Yoi's existing package discovery, explicit enablement, digest pinning, ToolRegistry, ordinary Tool history, and Plugin-layer permission enforcement.
|
||||||
|
|
||||||
|
## Motivation / background
|
||||||
|
|
||||||
|
Yoi currently has a functional minimal Plugin Tool MVP:
|
||||||
|
|
||||||
|
- package discovery / explicit enablement;
|
||||||
|
- Tool surface registration;
|
||||||
|
- minimal WASM Tool execution through a raw core-Wasm ABI;
|
||||||
|
- Plugin permission grants.
|
||||||
|
|
||||||
|
The raw ABI is intentionally narrow, but it pushes too much low-level work onto Plugin authors and future SDKs:
|
||||||
|
|
||||||
|
- `memory` export handling;
|
||||||
|
- `yoi_tool_call()` export convention;
|
||||||
|
- `input_len` / `input_read` / `output_write` pointer-length plumbing;
|
||||||
|
- JSON serialization and error encoding;
|
||||||
|
- host API import namespace conventions;
|
||||||
|
- ABI versioning for future `https` / `fs` / Ingress APIs.
|
||||||
|
|
||||||
|
Research of common Wasm extension systems points in the same direction:
|
||||||
|
|
||||||
|
- Extism-style systems provide a PDK so Plugin authors write normal typed functions while the PDK hides the raw ABI.
|
||||||
|
- Spin-style systems combine manifests, templates, SDKs, explicit outbound/file capabilities, and Wasm components.
|
||||||
|
- The WebAssembly Component Model standardizes typed imports/exports via WIT and canonical ABI instead of each host inventing its own pointer/length protocol.
|
||||||
|
|
||||||
|
Yoi should adopt that direction early enough that `https`, `fs`, SDK, authoring templates, and future Service/Ingress surfaces do not entrench a custom ABI that will be expensive to migrate later.
|
||||||
|
|
||||||
|
## Strategy / design direction
|
||||||
|
|
||||||
|
- Treat the Component Model as the preferred future Plugin runtime shape.
|
||||||
|
- New typed Plugin host APIs should be designed in WIT-compatible terms.
|
||||||
|
- `runtime.kind = "wasm-component"` should become the preferred runtime once implemented.
|
||||||
|
- Keep the current raw core-Wasm runtime as a compatibility / migration bridge until Component Model execution is validated.
|
||||||
|
- Current ABI name: `yoi-plugin-wasm-1`.
|
||||||
|
- Future component world should get an explicit version, e.g. `yoi:plugin/tool@1.0.0`.
|
||||||
|
- Preserve existing Yoi authority boundaries.
|
||||||
|
- Component imports are capability-shaped interfaces, not grants by themselves.
|
||||||
|
- Package discovery remains read-only.
|
||||||
|
- Enablement and Plugin grants remain explicit and fail closed before registration/execution/host API calls.
|
||||||
|
- Tool calls and results continue through ordinary ToolRegistry / history paths.
|
||||||
|
- Prefer a phased migration rather than a flag day.
|
||||||
|
1. Define WIT package/worlds for Tool Plugin and host APIs.
|
||||||
|
2. Add runtime manifest support for `wasm-component` alongside current `wasm`/core ABI.
|
||||||
|
3. Add host-side component execution and typed import/export binding.
|
||||||
|
4. Port or wrap `https` / `fs` host APIs through WIT-compatible interfaces.
|
||||||
|
5. Add authoring SDK/templates around the component world.
|
||||||
|
6. Keep or deprecate raw core-Wasm runtime based on migration evidence.
|
||||||
|
- Evaluate runtime cost explicitly.
|
||||||
|
- Current implementation uses `wasmi` for core Wasm.
|
||||||
|
- Component Model support likely points to `wasmtime::component` or a separate component backend, with packaging/build-size/runtime implications.
|
||||||
|
- Nix build validation is required for this migration.
|
||||||
|
|
||||||
|
## Success criteria / exit conditions
|
||||||
|
|
||||||
|
- Yoi has a documented WIT world for Tool Plugins and initial host APIs.
|
||||||
|
- A sample Rust Component Model Tool Plugin can be built and run by Yoi without raw pointer/length code in Plugin author source.
|
||||||
|
- Component runtime is selected explicitly by package manifest metadata and never by package presence alone.
|
||||||
|
- Component host API calls are still denied without matching Plugin grants.
|
||||||
|
- Tool outputs still use ordinary Tool result/history paths; no hidden context injection is introduced.
|
||||||
|
- Current core-Wasm Plugin tests either remain passing or are explicitly migrated with a compatibility decision.
|
||||||
|
- Packaging impact is measured and `nix build .#yoi` passes.
|
||||||
|
- Documentation explains the migration path for existing raw-ABI Plugin packages and future SDK authors.
|
||||||
|
|
||||||
|
## Decision context
|
||||||
|
|
||||||
|
- This Objective is medium-term context, not Ticket authority. Implementation still requires reading concrete Ticket bodies, threads, artifacts, and relations.
|
||||||
|
- The Component Model direction supersedes making Yoi's custom raw ABI the long-term authoring interface.
|
||||||
|
- Short-term `https` / `fs` work should avoid encoding choices that conflict with later WIT typing.
|
||||||
|
- Guest SDK work should either target Component Model directly or keep the raw ABI wrapper clearly transitional.
|
||||||
|
- MCP remains separate from Plugin. Component Model adoption for Plugin does not imply MCP server execution, MCP prompt/resource injection, or MCP trust policy changes.
|
||||||
0
.yoi/tickets/00001KVG0HR96/artifacts/.gitkeep
Normal file
0
.yoi/tickets/00001KVG0HR96/artifacts/.gitkeep
Normal file
53
.yoi/tickets/00001KVG0HR96/artifacts/relations.json
Normal file
53
.yoi/tickets/00001KVG0HR96/artifacts/relations.json
Normal file
|
|
@ -0,0 +1,53 @@
|
||||||
|
{
|
||||||
|
"version": 1,
|
||||||
|
"relations": [
|
||||||
|
{
|
||||||
|
"ticket_id": "00001KVG0HR96",
|
||||||
|
"kind": "depends_on",
|
||||||
|
"target": "00001KV5W3PHW",
|
||||||
|
"note": "Component Model runtime migrates the existing raw WASM Tool runtime.",
|
||||||
|
"author": "yoi ticket",
|
||||||
|
"at": "2026-06-19T13:21:01Z"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"ticket_id": "00001KVG0HR96",
|
||||||
|
"kind": "depends_on",
|
||||||
|
"target": "00001KV5W3PJ3",
|
||||||
|
"note": "Component runtime must preserve Plugin permission grant enforcement.",
|
||||||
|
"author": "yoi ticket",
|
||||||
|
"at": "2026-06-19T13:21:01Z"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"ticket_id": "00001KVG0HR96",
|
||||||
|
"kind": "related",
|
||||||
|
"target": "00001KSXRQ4G8",
|
||||||
|
"note": "Updates Plugin runtime/surface/host API design direction toward Component Model.",
|
||||||
|
"author": "yoi ticket",
|
||||||
|
"at": "2026-06-19T13:21:01Z"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"ticket_id": "00001KVG0HR96",
|
||||||
|
"kind": "related",
|
||||||
|
"target": "00001KVFD3YSV",
|
||||||
|
"note": "Inspection CLI should report component runtime metadata without execution.",
|
||||||
|
"author": "yoi ticket",
|
||||||
|
"at": "2026-06-19T13:21:01Z"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"ticket_id": "00001KVG0HR96",
|
||||||
|
"kind": "related",
|
||||||
|
"target": "00001KVFDX9AF",
|
||||||
|
"note": "https host API should be designed in WIT-compatible typed terms.",
|
||||||
|
"author": "yoi ticket",
|
||||||
|
"at": "2026-06-19T13:21:01Z"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"ticket_id": "00001KVG0HR96",
|
||||||
|
"kind": "related",
|
||||||
|
"target": "00001KVFDX9AY",
|
||||||
|
"note": "fs host API should be designed in WIT-compatible typed terms.",
|
||||||
|
"author": "yoi ticket",
|
||||||
|
"at": "2026-06-19T13:21:01Z"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
113
.yoi/tickets/00001KVG0HR96/item.md
Normal file
113
.yoi/tickets/00001KVG0HR96/item.md
Normal file
|
|
@ -0,0 +1,113 @@
|
||||||
|
---
|
||||||
|
title: 'Plugin: migrate WASM Tool runtime to WebAssembly Component Model'
|
||||||
|
state: 'ready'
|
||||||
|
created_at: '2026-06-19T13:18:58Z'
|
||||||
|
updated_at: '2026-06-19T13:21:01Z'
|
||||||
|
assignee: null
|
||||||
|
readiness: 'implementation_ready'
|
||||||
|
risk_flags: ['plugin', 'wasm', 'component-model', 'wit', 'runtime-backend', 'sandbox', 'packaging', 'sdk']
|
||||||
|
---
|
||||||
|
|
||||||
|
## Background
|
||||||
|
|
||||||
|
Yoi's current Plugin Tool runtime uses a raw core-Wasm ABI (`yoi-plugin-wasm-1`) with `yoi_tool_call`, exported `memory`, and host imports for input/output pointer-length plumbing. That was a good MVP for a small sandboxed runtime, but it should not become the long-term authoring interface.
|
||||||
|
|
||||||
|
Common Wasm extension systems usually provide a typed SDK/PDK, manifest, capability grants, templates, and inspection tooling. The WebAssembly Component Model provides a standard way to describe typed imports/exports via WIT and canonical ABI. Adopting it early prevents `https`, `fs`, SDK, and future Service/Ingress APIs from entrenching a Yoi-specific raw ABI.
|
||||||
|
|
||||||
|
This Ticket implements an explicit Component Model runtime path for Plugin Tool packages while preserving the existing package discovery, enablement, digest pinning, ToolRegistry, ordinary Tool history, and Plugin grant enforcement boundaries.
|
||||||
|
|
||||||
|
Research and direction are persisted in:
|
||||||
|
|
||||||
|
- `.yoi/objectives/00001KVG0HR9M/item.md` — Plugin Component Model migration Objective.
|
||||||
|
- `docs/design/plugin-component-model.md` — design research and policy.
|
||||||
|
- `docs/design/plugin-packages.md` — package runtime metadata direction.
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
- Add an explicit Component Model runtime kind for Plugin packages.
|
||||||
|
- Example manifest shape:
|
||||||
|
|
||||||
|
```toml
|
||||||
|
[runtime]
|
||||||
|
kind = "wasm-component"
|
||||||
|
component = "plugin.component.wasm"
|
||||||
|
world = "yoi:plugin/tool@1.0.0"
|
||||||
|
```
|
||||||
|
|
||||||
|
- Do not silently reinterpret existing raw core-Wasm packages.
|
||||||
|
- Current raw runtime remains explicit, e.g. `kind = "wasm"`, `abi = "yoi-plugin-wasm-1"`.
|
||||||
|
- Component runtime selection is driven by package manifest/runtime metadata.
|
||||||
|
- Define WIT package/worlds for the Plugin Tool runtime.
|
||||||
|
- Tool request / response / structured error types.
|
||||||
|
- Tool name and JSON input/output representation, or a better typed equivalent if decided during implementation.
|
||||||
|
- Initial host API interfaces should be WIT-compatible even if some APIs remain unimplemented.
|
||||||
|
- Add a host runtime backend capable of loading and invoking Component Model Plugin Tools.
|
||||||
|
- Evaluate whether this uses `wasmtime::component`, adapter tooling, or another backend.
|
||||||
|
- Keep runtime selected per package; discovery/inspection must not execute Plugin code.
|
||||||
|
- Preserve existing Plugin authority boundaries.
|
||||||
|
- Package discovery is read-only.
|
||||||
|
- Explicit enablement is required.
|
||||||
|
- Plugin grants are checked before Tool registration/execution and before host API calls.
|
||||||
|
- WIT imports are not authority by themselves.
|
||||||
|
- No ambient WASI filesystem/network/env is exposed.
|
||||||
|
- Preserve ordinary Tool behavior.
|
||||||
|
- Component Tool registration goes through existing ToolRegistry/model-visible schema path.
|
||||||
|
- Tool calls/results use ordinary Worker/Tool history path.
|
||||||
|
- No hidden context injection.
|
||||||
|
- Provide at least one sample Component Model Tool Plugin.
|
||||||
|
- Prefer Rust authoring path if feasible.
|
||||||
|
- Plugin author source should not contain raw pointer/length ABI plumbing.
|
||||||
|
- Add or update tests for both positive and negative paths.
|
||||||
|
- Component package discovery and manifest parsing.
|
||||||
|
- Component Tool registration.
|
||||||
|
- Component Tool execution.
|
||||||
|
- Grant denial before execution / host API access.
|
||||||
|
- Wrong world / missing export / incompatible component rejected.
|
||||||
|
- Existing raw core-Wasm Plugin runtime either still passes or has a recorded compatibility decision.
|
||||||
|
- Measure packaging/runtime impact.
|
||||||
|
- Binary size/build time impact if adding Wasmtime/component tooling.
|
||||||
|
- Nix packaging changes and `cargoHash` if dependencies change.
|
||||||
|
|
||||||
|
## Acceptance criteria
|
||||||
|
|
||||||
|
- A package with `runtime.kind = "wasm-component"` and the expected WIT world can be discovered, enabled, registered as a Tool, and executed.
|
||||||
|
- A sample Component Model Tool Plugin returns a normal Tool result through the ordinary Tool path.
|
||||||
|
- Plugin author code for the sample uses generated/SDK bindings rather than raw pointer/length imports/exports.
|
||||||
|
- Component Tool execution is denied without matching Plugin grants.
|
||||||
|
- Component host imports cannot bypass Yoi's Plugin grant model.
|
||||||
|
- Unsupported / wrong WIT world or missing required export fails closed with bounded diagnostic.
|
||||||
|
- Existing raw core-Wasm runtime remains explicitly supported or a migration/deprecation decision is recorded and tests are updated accordingly.
|
||||||
|
- `yoi plugin list/show` inspection path, if available, reports Component runtime metadata without executing the component.
|
||||||
|
- Documentation is updated with authoring/runtime instructions and migration notes.
|
||||||
|
- Validation includes relevant focused tests, `cargo fmt --check`, `git diff --check`, `cargo check` / `cargo test`, and `nix build .#yoi`.
|
||||||
|
|
||||||
|
## Non-goals
|
||||||
|
|
||||||
|
- Service surface implementation.
|
||||||
|
- Ingress surface implementation.
|
||||||
|
- WebSocket / Discord Gateway bridge.
|
||||||
|
- Inbound HTTP server.
|
||||||
|
- Replacing Plugin grants with WIT imports.
|
||||||
|
- Exposing WASI filesystem/network/env as ambient authority.
|
||||||
|
- MCP integration or MCP trust policy changes.
|
||||||
|
- A full public package registry or signature/trust-chain system.
|
||||||
|
|
||||||
|
## Implementation notes
|
||||||
|
|
||||||
|
- Keep raw core-Wasm ABI compatibility separate from Component Model support.
|
||||||
|
- Prefer WIT names that can version cleanly, such as `yoi:plugin/tool@1.0.0` and `yoi:host/https@1.0.0`.
|
||||||
|
- If Wasmtime is introduced, update Nix packaging and record dependency/build-size impact.
|
||||||
|
- If a staged approach is necessary, first land WIT definitions and manifest parsing, then runtime execution in a follow-up. Do not pretend manifest parsing alone completes this Ticket.
|
||||||
|
- `https` and `fs` host API work should avoid long-term raw ABI coupling; component-compatible request/response/path/error records are preferred.
|
||||||
|
|
||||||
|
## Related work
|
||||||
|
|
||||||
|
- `00001KVG0HR9M` — Objective: Plugin Component Model migration.
|
||||||
|
- `docs/design/plugin-component-model.md` — design research and migration direction.
|
||||||
|
- `docs/design/plugin-packages.md` — package runtime metadata direction.
|
||||||
|
- `00001KV5W3PHW` — Plugin Tool execution with minimal WASM runtime.
|
||||||
|
- `00001KV5W3PJ3` — Plugin permission grant enforcement.
|
||||||
|
- `00001KVFDX9AF` — Plugin https host API.
|
||||||
|
- `00001KVFDX9AY` — Plugin fs host API.
|
||||||
|
- `00001KVFD3YSV` — Plugin read-only CLI inspection list/show.
|
||||||
|
- `00001KSXRQ4G8` — Plugin runtime / surface / minimal host API model design.
|
||||||
7
.yoi/tickets/00001KVG0HR96/thread.md
Normal file
7
.yoi/tickets/00001KVG0HR96/thread.md
Normal file
|
|
@ -0,0 +1,7 @@
|
||||||
|
<!-- event: create author: "yoi ticket" at: 2026-06-19T13:18:58Z -->
|
||||||
|
|
||||||
|
## 作成
|
||||||
|
|
||||||
|
LocalTicketBackend によって作成されました。
|
||||||
|
|
||||||
|
---
|
||||||
123
docs/design/plugin-component-model.md
Normal file
123
docs/design/plugin-component-model.md
Normal file
|
|
@ -0,0 +1,123 @@
|
||||||
|
# Plugin Component Model migration
|
||||||
|
|
||||||
|
Yoi's current Plugin Tool runtime uses a narrow core-WebAssembly ABI. That was the right MVP shape because it made sandboxing, bounded input/output, and fail-closed host imports explicit. It should not become the long-term authoring interface.
|
||||||
|
|
||||||
|
The preferred direction is to adopt the WebAssembly Component Model for Plugin Tool authoring and host APIs. Component Model adoption means Plugin interfaces are described as typed WIT worlds and lowered through the canonical ABI, instead of every Plugin author or SDK wrapper hand-writing pointer/length memory plumbing.
|
||||||
|
|
||||||
|
## What Component Model changes
|
||||||
|
|
||||||
|
A core Wasm module exposes low-level functions and memory. Yoi's current Plugin Tool ABI is shaped like this:
|
||||||
|
|
||||||
|
```text
|
||||||
|
export memory
|
||||||
|
export yoi_tool_call() -> i32
|
||||||
|
import yoi:tool/tool_name_len() -> i32
|
||||||
|
import yoi:tool/tool_name_read(ptr, len) -> i32
|
||||||
|
import yoi:tool/input_len() -> i32
|
||||||
|
import yoi:tool/input_read(ptr, len) -> i32
|
||||||
|
import yoi:tool/output_write(ptr, len) -> i32
|
||||||
|
```
|
||||||
|
|
||||||
|
This is small and auditable, but it makes raw ABI details part of the authoring model. A Component Model world can instead describe a typed contract:
|
||||||
|
|
||||||
|
```wit
|
||||||
|
package yoi:plugin;
|
||||||
|
|
||||||
|
interface tool {
|
||||||
|
record request {
|
||||||
|
tool-name: string,
|
||||||
|
input-json: string,
|
||||||
|
}
|
||||||
|
|
||||||
|
record response {
|
||||||
|
output-json: string,
|
||||||
|
}
|
||||||
|
|
||||||
|
variant tool-error {
|
||||||
|
invalid-input(string),
|
||||||
|
denied(string),
|
||||||
|
failed(string),
|
||||||
|
}
|
||||||
|
|
||||||
|
run: func(req: request) -> result<response, tool-error>;
|
||||||
|
}
|
||||||
|
|
||||||
|
world tool-plugin {
|
||||||
|
export tool;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The exact WIT is still design work, but the important boundary is fixed: the Plugin author sees typed values and generated bindings; the host sees typed imports/exports; Yoi still enforces package enablement and Plugin grants outside the component.
|
||||||
|
|
||||||
|
## External patterns considered
|
||||||
|
|
||||||
|
Common Wasm extension systems normally ship more than a runtime:
|
||||||
|
|
||||||
|
- Extism-style systems provide host runtimes plus language PDKs. Plugin authors write normal typed functions while the PDK hides the raw ABI and host functions remain explicit.
|
||||||
|
- Spin-style systems combine a manifest, language SDK/templates, default-deny outbound/file capabilities, and Wasm components.
|
||||||
|
- wasmCloud-style systems separate components from capability providers and connect them through typed interfaces.
|
||||||
|
- The Component Model standardizes the interface layer with WIT and canonical ABI so host APIs can be versioned and bindings generated across languages.
|
||||||
|
|
||||||
|
The shared lesson is that a usable Wasm Plugin system needs a manifest, explicit capabilities, generated or hand-written SDK bindings, examples/templates, inspection tooling, and a versioned ABI. Yoi already has the manifest/discovery/enablement/grant/runtime foundation; the missing long-term piece is the typed component authoring interface.
|
||||||
|
|
||||||
|
## Yoi policy
|
||||||
|
|
||||||
|
Adopting the Component Model must not change Yoi's authority model:
|
||||||
|
|
||||||
|
- Package discovery is inventory only and does not register or execute a Plugin.
|
||||||
|
- Explicit enablement is required before any Tool surface is registered.
|
||||||
|
- Plugin grants are required before runtime execution and before `https` / `fs` / future host API calls.
|
||||||
|
- Component imports are not authority by themselves; host-side grant checks remain authoritative.
|
||||||
|
- Tool calls and Tool results continue through the ordinary ToolRegistry and Worker history path.
|
||||||
|
- No hidden context injection is introduced by component imports, resources, prompts, or SDK helpers.
|
||||||
|
- Plugin SDKs and templates are authoring aids, not trust boundaries.
|
||||||
|
|
||||||
|
## Migration shape
|
||||||
|
|
||||||
|
Yoi should support Component Model as an explicit runtime kind rather than silently changing existing raw-ABI packages.
|
||||||
|
|
||||||
|
Possible manifest direction:
|
||||||
|
|
||||||
|
```toml
|
||||||
|
[runtime]
|
||||||
|
kind = "wasm-component"
|
||||||
|
component = "plugin.component.wasm"
|
||||||
|
world = "yoi:plugin/tool@1.0.0"
|
||||||
|
```
|
||||||
|
|
||||||
|
The current raw core-Wasm runtime can remain explicit during migration:
|
||||||
|
|
||||||
|
```toml
|
||||||
|
[runtime]
|
||||||
|
kind = "wasm"
|
||||||
|
entry = "plugin.wasm"
|
||||||
|
abi = "yoi-plugin-wasm-1"
|
||||||
|
```
|
||||||
|
|
||||||
|
The migration should be phased:
|
||||||
|
|
||||||
|
1. Define WIT packages/worlds for Tool Plugin and initial host APIs.
|
||||||
|
2. Add manifest/schema support for `runtime.kind = "wasm-component"` without executing it during discovery.
|
||||||
|
3. Add a component runtime backend and typed host import/export binding.
|
||||||
|
4. Port `https` and `fs` host API designs to WIT-compatible interfaces.
|
||||||
|
5. Add a Rust authoring SDK/template around the component world.
|
||||||
|
6. Decide whether the raw ABI remains supported, becomes legacy-only, or is deprecated after examples and tests move.
|
||||||
|
|
||||||
|
## Runtime/backend caution
|
||||||
|
|
||||||
|
The current implementation uses `wasmi` for core Wasm. Component Model support will likely require a different backend or a significantly richer component adapter path, such as `wasmtime::component` plus generated bindings. That has consequences for binary size, Nix packaging, build time, runtime limits, and sandbox policy. The migration Ticket must measure and validate those effects explicitly.
|
||||||
|
|
||||||
|
If a component backend is added, keep it selected by package runtime metadata and Profile/feature policy. Do not make all Plugin packages depend on component execution during discovery or inspection.
|
||||||
|
|
||||||
|
## Relationship to pending host APIs
|
||||||
|
|
||||||
|
`https` and `fs` host API Tickets should avoid baking in raw pointer/length interfaces as the long-term authoring contract. If they land before the component runtime, implement them in a way that can be represented as WIT records/results later, and document raw ABI wrappers as transitional.
|
||||||
|
|
||||||
|
For example, `https` should be modeled as typed request/response data with explicit grant checks for host/method/path/body bounds. `fs` should be modeled as scoped read/list/write operations with path normalization and root-escape rejection. Those concepts translate well to WIT.
|
||||||
|
|
||||||
|
## Non-goals
|
||||||
|
|
||||||
|
- Component Model adoption does not imply WASI filesystem/network access.
|
||||||
|
- It does not replace Plugin grants with WIT imports.
|
||||||
|
- It does not introduce Service, Ingress, WebSocket, or inbound HTTP by itself.
|
||||||
|
- It does not merge Plugin and MCP. MCP remains a separate untrusted tool/resource/prompt bridge with its own policy.
|
||||||
|
|
@ -52,6 +52,15 @@ entry = "plugin.wasm"
|
||||||
abi = "yoi-plugin-wasm-1"
|
abi = "yoi-plugin-wasm-1"
|
||||||
```
|
```
|
||||||
|
|
||||||
|
The preferred future WASM authoring/runtime shape is the WebAssembly Component Model, recorded in [Plugin Component Model migration](plugin-component-model.md). Component packages should be explicit and source-compatible rather than silently changing the existing raw core-Wasm runtime:
|
||||||
|
|
||||||
|
```toml
|
||||||
|
[runtime]
|
||||||
|
kind = "wasm-component"
|
||||||
|
component = "plugin.component.wasm"
|
||||||
|
world = "yoi:plugin/tool@1.0.0"
|
||||||
|
```
|
||||||
|
|
||||||
First-pass fields accepted by the parser:
|
First-pass fields accepted by the parser:
|
||||||
|
|
||||||
- `schema_version`: required integer; unsupported versions fail closed.
|
- `schema_version`: required integer; unsupported versions fail closed.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue
Block a user