Open guest271314 opened 1 year ago
This is a Native Messaging host written in C https://github.com/guest271314/native-messaging-webassembly/blob/main/nm_c.c (I also compiled a C++ version to WebAssembly), compiled to WASI using WASI-SDK that just echoes 1 MB of data.
I have written Native Messaging hosts using Python, JavaScript (QuickJS; txiki.js; Bun; Node.js; Deno; Bash version is W.I.P.) https://github.com/guest271314/NativeMessagingHosts, in part to gain empirical information about the resources and dependencies, if any, each programming language or runtime uses to achieve the same result, and in another part, though the totoality of my reasoning, to not become attached to one programming language - though I write most of my code in JavaScript.
This is the Native messaging protocol
This is what a manifest looks like
We connect to the host using either
connectNative()
for extended, potentially persistent connectionsor sending (potentially receiving) a single message
There is also
batively_connectable
which is not widely documented or implemented https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/extensions/api/messaging/native_messaging_launch_from_native.cc where the host or extension automatically makes a connection.The message format is JSON, which is a format capable of sending and receiving essentially any type of serialized data in the format
[0, ..., 255]
etc.Each message is preceded by the length of the JSON message, in each direction.
In the context of WASI messaging this is a very simple and extensible messaging protocol. We can connect to any host using the name of the host, e.g.,
Working example of above pattern https://github.com/guest271314/captureSystemAudio/tree/master/native_messaging/capture_system_audio.
For the use case of getting lists of possible radio stations, or other fields of interest a single message to the host from the client and from the host to the client (or whtever terminology we want to use here, e.g., "peers") using the name of the service or peer who provides such a list of possible message channels or peers
We can use whatever underlying transport we want. HTTP/2, HTTP/3, QUIC, WebRTC, etc.
Very simple to use. Nothing unnecessarily complicated about the protocol nor configuration. Achieves real-time audio streaming without gaps or glitches using JSON (or a JavaScript object).