Closed guest271314 closed 1 year ago
@danbugs could you please take a look?
@guest271314 – apologies for the late response.
While WebTransport and WebSocketStream are different from the typical messaging systems like MQTT, Kafka, and NATS, afaik, they do share the fundamental characteristic of enabling bidirectional communication. With that, it should be possible to have them be implementors for this interface.
Is there anything you think is missing or is this mostly just addressing the README
's wording?
~btw, I've attempting running your native-messaging-webassembly
repo, but got an error that I figured I'd pass back to you:
.
Also, here's some more info I found on it: https://github.com/NativeMessaging/Documentation/blob/06e2e75a1f3cab327c25b02406e6c88fc034a1b4/Chrome/Errors.md#error-when-communicating-with-the-native-messaging-host
@guest271314 – apologies for the late response.
No worries. Here we are.
Is there anything you think is missing or is this mostly just addressing the README's wording?
I think local usage, not exclusively tailored to messaging with some external "microservice" should be included in the goals, so later on folks can't say this is just about "partners" external services. E.g., it was/is not clear at all how to use Fastly's js-compute-runtime standalone - without dependence or expectation of Node.js and npm
being installed https://github.com/fastly/js-compute-runtime/issues/445.
~btw, I've attempting running your native-messaging-webassembly repo, but got an error that I figured I'd pass back to you:
Did you follow the relevant instructions? Are wasmtime
, and the .sh
files marked executable?
I justed tested on Chromium 114 .
I think local usage, not exclusively tailored to messaging with some external "microservice" should be included in the goals, so later on folks can't say this is just about "partners" external services. E.g., it was/is not clear at all how to use Fastly's js-compute-runtime standalone - without dependence or expectation of Node.js and npm being installed https://github.com/fastly/js-compute-runtime/issues/445.
That makes sense to me. Also, usually, it's very possible to just run brokers locally (i.e., we have an example of that running Mosquitto in SpiderLightning ~ you can see it here: https://github.com/deislabs/spiderlightning/pull/183), so I hope we'll be covered there.
Did you follow the relevant instructions? Are wasmtime, and the .sh files marked executable?
I'll create an issue in your repo for native-messaging-webassembly to talk about this further.
That makes sense to me. Also, usually, it's very possible to just run brokers locally (i.e., we have an example of that running Mosquitto in SpiderLightning ~ you can see it here: https://github.com/deislabs/spiderlightning/pull/183), so I hope we'll be covered there.
Native Messaging protocol https://developer.chrome.com/docs/apps/nativeMessaging/#native-messaging-host-protocol, https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging is far simpler. Uint32Array
(JavaScript) message length preceding message encoded as JSON. The format is suitable for single messages up to 1MB from client to host; and "real-time" streaming. e.g., https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/capture_system_audio/capture_system_audio.c, et al.
Rust has been a challenge to install on a temporary file system, i.e., for embedding systems; Rust tool chain requires onver 1GB to install, before downloading any crates. I managed to build runjs from https://github.com/denoland/roll-your-own-javascript-runtime, when I continued wih tokio crate.
This will be useful to provide a means to create a message channel between local applications and browsers, e.g., Native Messaging https://github.com/guest271314/native-messaging-webassembly, not just "service providers, and or cloud providers)".
This can work something like
WebTransport
andWebSocketStream
where we write to the application withwritable.writer.write()
and read withreadable.reader.read()
.