Summary
Add a new OpenDAL backend that leverages the wasi:filesystem interface for file operations. This enables OpenDAL to access the host filesystem when running as a WebAssembly component, with the host runtime (e.g., wasmtime, wasmer) providing the actual filesystem implementation.
Motivation
Currently, the services-fs backend cannot compile to wasm32-wasip2 because it depends on tokio's filesystem features, which are not supported on WASM targets.
However, WASM components can access the host filesystem through the standardized wasi:filesystem interface. A wasi-fs backend would:
- Enable filesystem access in WASM components — Components could read/write files preopened by the host runtime
- Complement existing backends —
memory and s3 work on WASM, but there's no local filesystem option
- Leverage existing WASI ecosystem — Runtimes like wasmtime already implement
wasi:filesystem
Proposed Implementation
A new services-wasi-fs feature/backend that:
- Imports
wasi:filesystem/types and wasi:filesystem/preopens interfaces
- Uses
wasi:io/streams for read/write operations
- Works with preopened directories provided by the host
- Compiles to
wasm32-wasip2 target only (or conditional compilation)
Use Case
We're building WASM components that expose storage capabilities. We want to:
- Create an OpenDAL-based storage component
- Export
wasi:filesystem interface for downstream consumers
- Support multiple backends (memory, S3, and host filesystem)
Without a wasi-fs backend, components cannot access files that the host runtime preopens for them.
Research Notes
| Backend |
WASM-compatible |
Notes |
services-memory |
✅ |
Works out of the box |
services-s3 |
✅ |
Works with reqwest/reqsign |
services-fs |
❌ |
Requires tokio fs (not WASM-compatible) |
services-wasi-fs |
🆕 |
Proposed — uses wasi:filesystem imports |
Related
Summary
Add a new OpenDAL backend that leverages the
wasi:filesysteminterface for file operations. This enables OpenDAL to access the host filesystem when running as a WebAssembly component, with the host runtime (e.g., wasmtime, wasmer) providing the actual filesystem implementation.Motivation
Currently, the
services-fsbackend cannot compile towasm32-wasip2because it depends on tokio's filesystem features, which are not supported on WASM targets.However, WASM components can access the host filesystem through the standardized
wasi:filesysteminterface. Awasi-fsbackend would:memoryands3work on WASM, but there's no local filesystem optionwasi:filesystemProposed Implementation
A new
services-wasi-fsfeature/backend that:wasi:filesystem/typesandwasi:filesystem/preopensinterfaceswasi:io/streamsfor read/write operationswasm32-wasip2target only (or conditional compilation)Use Case
We're building WASM components that expose storage capabilities. We want to:
wasi:filesysteminterface for downstream consumersWithout a
wasi-fsbackend, components cannot access files that the host runtime preopens for them.Research Notes
services-memoryservices-s3services-fsservices-wasi-fswasi:filesystemimportsRelated