JMLX42 commented on PR #7005:
URL: https://github.com/apache/opendal/pull/7005#issuecomment-3649669668
## WASI Usability Investigation
While implementing integration tests, I discovered a fundamental
architectural issue with using the wasi-fs service.
### The Problem
The wasi-fs service implementation is correct - `WasiFsCore` works perfectly
with blocking WASI Preview 2 APIs. However, **there's no way to use it through
OpenDAL's public API** because the entire Operator infrastructure depends on
tokio:
1. **Async `Operator`** - Requires tokio runtime to poll futures
2. **`blocking::Operator`** - Requires `tokio::runtime::Handle` to call
`block_on`:
```rust
// From core/core/src/blocking/operator.rs
pub struct Operator {
handle: tokio::runtime::Handle, // Requires tokio!
op: AsyncOperator,
}
impl Operator {
pub fn new(op: AsyncOperator) -> Result<Self> {
Ok(Self {
handle: Handle::try_current() // Needs tokio runtime
.map_err(|_| Error::new(...))?,
op,
})
}
}
```
Tokio doesn't compile for `wasm32-wasip2`:
```
error: Only features sync,macros,io-util,rt,time are supported on wasm.
```
### Current State
- ✅ `WasiFsCore` - Works (synchronous, uses WASI Preview 2 APIs directly)
- ❌ `Operator` - Cannot be used (requires async runtime)
- ❌ `blocking::Operator` - Cannot be used (requires tokio handle)
### Possible Solutions
1. **Expose `WasiFsCore` as public API** - Simple but breaks consistency
with other services
2. **WASI-specific Operator** - New operator type that doesn't require tokio
3. **Alternative async runtime for WASI** - Use `smol` or `async-executor`
instead of tokio
4. **Native blocking trait methods** - Let wasi-fs implement blocking
methods directly without wrapping
### Questions for Maintainers
- Is WASI support a priority for OpenDAL?
- What's the preferred approach to make wasi-fs actually usable?
- Should we hold this PR until there's a path to usability?
The service implementation is complete and correct, but without a usable
API, it's effectively dead code.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
