Zephyr and WebAssembly roadmap

[fitbit]

Zephyr and WebAssembly roadmap

[barbibulle]

Hi @beriberikix.
For Zephyr, I have a proof of concept/experiment that's functional enough to play with, but not robust or documented enough to release (at least not with a lot of caveats). When working on the port, I ran into limitations of the Zephyr networking stack which made it difficult to have an efficient implementation without making some changes in Zephyr's IP stack, which I didn't have the time to engage with at the time. I think the discussion of my investigations, then, was on Slack, so I don't have a written record of it. If you're interested in taking a look, I could easily push my experimental branch up.

About WebAssembly, I think that has a lot of potential, because of Web Bluetooth, which has been supported by some browsers for a while, especially Chrome. This allows a direct connection of the Golden Gate stack over Bluetooth with no software install. What's included in the experimental port that's in the repo is only partial, though: it gives access to the networking stack, by exposing some of the C functions via Web Assembly, and can connect the stack to Bluetooth input/output over GATT. What's not there yet is an integration of CoAP. There are two ways to do that, with pros and cons for each. The first way would be to simply provide some JS bindings for the C functions of the Golden Gate CoAP API. This would give access to all the CoAP functionality that's in our C library, and all the testing that it has gone through. But as a downside, the API wouldn't necessarily be very idiomatic for a Javascript developer. The second option is to use a Javascript CoAP library that can run in a browser, and just send the CoAP datagrams to/from the stack with a simple JS/WebAsm binding. That would be fairly simple, but the existing JS libraries for CoAP we've found so far aren't necessarily full featured and/or robust (but since they're open source, there's definitely an opportunity to contribute.

We don't have a set roadmap or timing for continuing work on those initial PoCs at this point, but I'd be happy to help anyone who would like to work on it.

[beriberikix]

Thanks for the prompt reply!

If you're interested in taking a look, I could easily push my experimental branch up.
I'd be interested in taking a look, especially to understand the gap in Zephyr's IP stack. Unfortunately the Slack workspace doesn't retain old conversations.

About WebAssembly...There are two ways to do that, with pros and cons for each.
For first way, presumably the JS binding could add some syntactic sugar to be more idiomatic? Agree with the assessment of the second option, the current JS CoAP libraries are functional but missing what I'd consider necessary (I've personally moved to Go for that reason.)

What transport would you be using in the browser? Do you envision encapsulating CoAP/UDP over HTTP, WebSockets or WebRTC in an abstract way (I think GG does that in general), or adapt something from RFC 8283? Sadly the browser doesn't have a socket API, and doesn't like it will ever.

[barbibulle]

The way it works here is that the browser communicates with the other device over Bluetooth (could be an IoT device, a phone, or anything that you connect to over Bluetooth with GATT), using the WebBluetooth API offered by the browser. The data packets received from WebBluetooth are then injected into the Golden Gate network stack from Javascript with a Web Assembly call. The stack processes the packets, until eventually the come out of the other side of the stack as CoAP datagrams, which would then be sent back to the Javascript layer. The same applies in the other direction.
So:
[JS APP] <--(wasm)--> Golden Gate stack <--(wasm)--> JS <--(Web Bluetooth)--> OS BLE Stack <--> ... other BLE device

So, while the browser doesn't have a socket API, it doesn't matter, because all the socket/IP stuff happens in the Golden Gate library, which is compiled as a Web Assembly module. The way in/out of the browser is through Bluetooth with the Web Bluetooth API.

Unfortunately, the current Web Bluetooth API only offers a subset of what Bluetooth can do: you can only act as a BLE Central (i,e connect TO a BLE peripheral) and only as a GATT client (communicating with a GATT server on the peripheral). I hope that future versions of that API will allow for the BLE peripheral and GATT server roles, so that you could connect two browsers to each other. For now, the only possible topology is Browser -> mobile-app/iot

[beriberikix]

So, while the browser doesn't have a socket API, it doesn't matter

Ah, that makes complete sense!

future versions of that API will allow for the BLE peripheral and GATT server roles

FWIW Chrome has a tracker for "Project Fugu," a larger effort to bring OS-like capabilities to the web. Here's the tracker for the Peripheral role.

[beriberikix]

Is platform support like Zephyr being tracked anywhere?