I came across your issue while reading up on all the various pieces relevant to our challenge. Finally I’m starting to understand the complexity of this puzzle. I’ll lay out my journey here.
Briefly, if I understand correctly:
safe_app relies on a few crates in its dependency tree that have code written for specific targets, except for the
wasm32-unknown-unknown target. These are packages like
memmap that interact with low-level OS APIs.
Braindumping the possibilities for
- I found a ‘WASM-enabled’ crate that also implements allocation for Unix and Windows. The SAFE library
self_encryption would then use that instead of
memmap I assume. (I’m no expert at Rust and the SAFE libraries so forgive me if I’m incorrect to assume anything here.)
- Else you would need to write a patch (or submit a PR) for
memmap to support a WASM target. (Like Crichton mentioned.)
- Or wait for the WASM/Rust ecosystem to mature and expect everything to work in a few years.
- Implement the
memmap if that is at all possible. @pierrechevalier83 (The
sequencer seems the only piece of code that
safe_app relies on that uses
fs2 things are a little more confusing to me. From WASM apparently the
libc from Emscripten has a virtual filesystem.
fs2 relies on
libc only for Unix, so might be easy to fix
fs2 to rely on
libc for WASM too.
Is this something you considered, @hunterlester? I’m not sure how this affects the feasibility of a
safe_app WASM library…
Taking all the above into account I am a little less optimistic about the ease of what I described in the OP .
But, I have though of an alternative, be it a bit complex. This would be to have a library similar to
safe_app_nodejs, but instead of abstracting away the
safe_app::ffi API it would expose the API fully as a module. (This might be done with
node-ffi like now, or as a Node.js Addon (perhaps with Neon).)
This module would be imported from JS (or WASM) as
import safe_ffi from 'safe_ffi'. Where
safe_ffi then equals the
safe_app::ffi namespace from Rust.
From WASM this module can also be imported and called. If the module is a Node.js Addon the performance should be quite good.
Now, assume a simple Rust library is written that depends on
safe_app. I assume targeting Linux/Windows would result in linking to
safe_app statically or dynamically (not sure exactly). But, targeting WASM the library should ‘link’ to the JS module. This might be done in Rust with
cfg_if like here in
wee_alloc or other mechanisms (not sure exactly). If targeting WASM it would opt to rely on externally defined functions that are exactly like
I welcome any feedback or correction on what I wrote. I would love to further pursue this as a side project. Rust excites me a lot more than I expected.