Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile core to WASM #52

Open
orthecreedence opened this issue May 24, 2018 · 5 comments
Open

Compile core to WASM #52

orthecreedence opened this issue May 24, 2018 · 5 comments

Comments

@orthecreedence
Copy link
Member

@orthecreedence orthecreedence commented May 24, 2018

This would enable Turtl web clients. Not that I personally approve of web clients, but who am I to judge?

The core is in Rust, and Rust uses LLVM, and LLVM has a WASM target, so a majority of the work is done. I think the real issue is picking apart every single little issue that each crate has with being compiled to WASM. Also not sure about threading support and all that. I think FS support works via IndexedDB, but we use synchronous FS access and IDB is async...so how the hell does that work? Lots of questions.


Some resources:

@orthecreedence
Copy link
Member Author

@orthecreedence orthecreedence commented Oct 16, 2018

I'm moving this to roadmap. Not sure when it will get in, but I'm actually thinking this is more and more important. I'd like to launch a web version of Turtl at some point, and just be explicit about the dangers of it. Also, I know the Framanotes folks would like this as well.

@ldidry
Copy link

@ldidry ldidry commented Oct 16, 2018

Also, I know the Framanotes folks would like this as well.

Awww… 🤗 ❤️

Thank you!

@orthecreedence
Copy link
Member Author

@orthecreedence orthecreedence commented Oct 16, 2018

Of course!

@orthecreedence
Copy link
Member Author

@orthecreedence orthecreedence commented Dec 30, 2018

I did some work on this this past week. I ran into some issues...mainly some of the libraries turtl-core depends on use the libc rust crate which does not define a lot of values needed when compiling the wasm target. See:

I'm not exactly sure where to go from here. It seems rust itself compiles just fine to wasm, but when linking against C libs, it would need to make assumptions that would probably break things. There are two paths forward:

  1. Wait until rust/c play nicely together when targeting wasm. Obviously this is a waiting game.
  2. Replace all non-rust dependencies with rust-specific libraries (basically get rid of all *-sys crates). SQLite seems to work fine, actually, but openssl/libsodium (our heroic crypto libs) are problems. I haven't seen any pure-rust libraries that provide all the needed alternatives. Also, I don't like this route as much, because at some point we're going to want to do things like OCR and that really does require C libraries. In other words, playing nicely with C is going to be needed eventually, like it or not.

Note that there is an example of a conversion of compiling libsodium to wasm (https://github.com/alexcrichton/wasm-sodium) but it is old and full of horrible warnings. Plus that does still leave openssl (although this dependency will be dropped in wasm because it would primarily be used for the HTTP client, and wasm already has XHR). So, really, just libsodium...

@orthecreedence
Copy link
Member Author

@orthecreedence orthecreedence commented May 7, 2020

Note: currently blocked by koute/stdweb#398.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.