WASM support

[madig]

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"?

[cmyr]

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.

[madig]

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.