Open madig opened 10 months ago
great question.
I would start by thinking about how this would be expected to work, form JS land; as in, what do we imagine the user wanting to do? I suppose whatever they do will probably be mediated by the File
and FileList
APIs, although I'm really not very up on javascript, and maybe there's some other convention.
The simplest approach I can think of is to factor out the responsibility for fetching the bytes for a given path, and have some sort of PathResolver
trait that has a simple impl for the current case, and something a bit more involved for the web case? But I imagine we would want to experiment a bit before settling on a design.
One usecase I'm thinking about is reading and writing metadata in UFOs (think fontinfo) and Designspaces. So, loading and saving in Rust and passing objects over to JS and back.
The library compiles if you enable the "js" feature for uuid, but according to https://rustwasm.github.io/docs/book/reference/add-wasm-support-to-crate.html, direct I/O is a no-no, and norad is full of paths (as are UFOs). How could norad be rewritten to have the user be able to "bring their own I/O"?