Enable wasm32 compilation and runtime of the binary-port-access lib

[gRoussac]

As MVP Enable wasm32 compilation and runtime of the nested binary-port-access library.

Basically expose the binary-port-access lib as intended for Rust (non wasm32) / NodeJs (wasm32) / Browser WebSockets (wasm32)

• Rust remains the same a previous aka a TCP connection
• In Node.js, it uses raw TCP connections via the net module.
• In non-Node.js environments (typically browsers), it uses WebSockets.

Note that browsers have CORS (Cross-Origin Resource Sharing) restrictions, so the WebSocket requests should/may be addressed to a WebSocket proxy.

The added communication module provides both shared and platform-specific functionalities for managing communication processes.
- common.rs
- wasm32.rs Contains WebAssembly-specific (wasm32 target) communication utilities, available only when compiled for WebAssembly.

A TODO remains to replace usage of js_sys::eval on Node.js (script is local, not remote so no security issue but nice to change to global function execution with js_sys::Reflect::apply which should be more appropriate)

Could not make it work without eval because net library is required for NodeJs through require

NodeJs

Chromium Browser

[wojcik91]

LGTM, great documentation. I'd prefer if someone with more subject matter experience also looked through this

[wojcik91]

Since we don't use a --release profile I think the make build step is currently just duplicating stuff that is later done by other steps.

[gRoussac]

I added a

build-for-release:
	cargo build --release

there was not real release process here but I don't believe other steps include a build, like test / lint / fmt / audit, test does not build

Correct me please if I miss the point.

[igor-casper]

Looks fine by me, but see the suggestions.

[igor-casper]

Not a fan of using a random number generator here... u16 is small enough to where you will run into collisions quickly -- from my testing, around 317 iterations. Given the size of this type, it's plausible to experience collisions way sooner than that too. Not a big deal, but there should be a simpler way of tackling this. Would a counter not be enough?

[gRoussac]

Hi, That's a good point. usually it's a u64 in sidecar/node, not here as per request def in node. (It does not really matter to have repetition as soon as they are not to much successive, I think previous code was sending 0.)

I added the counter as suggested.

    let request_id = COUNTER.fetch_add(1, Ordering::SeqCst); // Atomically increment the counter

[gRoussac]

@igor-casper Actually counter is not that great because in CLI it will be always 0, so collision very fast. The counter starts at 0 at every request. A collision every 317 iterations was actually probably better than always 0.

[igor-casper]

@gRoussac You're probably right for the purposes of the client, but that's a CLI issue; As a standalone library, I think it should do its best to work in any context and shouldn't cater to just the client. How about you expose a method in the lib for manually assigning a value to the counter, so that downstream has the ability to decide for themselves? (CLI could use this to initialize it to a random value etc.)

[igor-casper]

@gRoussac please consider #11 , I think it's a decent solution

[devendran-m]

Hi @gRoussac ,
PR is approved and ready for merge.

[gRoussac]

@wojcik91 @igor-casper Thanks for your good review I appreciate. I think I treated it please give a last check at commit 94c871e
while I am testing it live before merging. cc @devendran-m

[gRoussac]

@zajko @devendran-m I think I ported your last changes but I didn't implement send_raw for wasm32 as I don't see the purpose yet for wasm32