-
-
Notifications
You must be signed in to change notification settings - Fork 159
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
Add WASM/WebBluetooth Support #13
Comments
This will basically be a wrapper around wasm_bindings WebSys, which still needs a gecko style WebIDL impl for WebBluetooth written for it. Guess who's probably doing that. :| |
WebBluetooth IDL support has landed into web-sys, and a WASM implementation is available at https://github.com/buttplugio/buttplug-rs-ffi in the WASM module. This could probably be ported over here at any time (though some web-sys IDL generation fixes are still needed) |
BTW, if someone sees this and wants to try to do it, you will most likely want to talk to me first. Getting the lifetimes right for the WASM/JS execution model is tricky. |
How's this going? |
^^ Any Progress? |
Having WASM support would be awesome! Since it is not currently supported, I have resorted to using this crate and the web-sys using an even more abstracted API |
Hi. I'm currently in the process of integrating btleplug to access ble from elixir via rustler https://hex.pm/packages/rustler_btleplug. Noticed this issue regarding supporting web bluetooth and was wondering what the point is of accessing ble via webassembly instead of rust or javascript? In a typical scenario what would be the scope and target application to integrate a webassembly btleplug library? wasm runtime on "anything"? |
Because sometimes you want to write rust to run on the web. For instance, the library I maintain on top of this crate is written in rust, but can compile to WASM and run on the web as well as on various native desktop/mobile platforms. It gives me one codebase for all platforms. A WASM btleplug will still call into the WebAPIs like WebBluetooth (I wrote the webapi bindings for that), but that will be hidden behind our generalized API. |
Not particularly sure how it'll be useful, but its the future, so why not.
Pretty much all of the API redesigns will need to happen before this I'm guessing, as we'll need to figure out how futures will convert and what not. Lots to think about.
The text was updated successfully, but these errors were encountered: