Developing a plugin for tutman96's plugin system... I'm stuck

[MaffooClock]

I'm working on a plugin that uses @tutman96's plugin system (discussion #9, PR #10). I understand that this is all new and not feature-complete, so I'm not asking for support, but I'd like to ask for a little guidance from Go developers who are clearly far more skilled than I am 😎

In discussion #101, I posited accessing the UART via the Extension Port. I built my own UART-to-RS232 cable (since the official serial console extension is not yet available) and was able to communicate with an external KVM via serial. Now, I'd like to build upon Mr. Tuttle's plugin system to make it easy for anyone with a serial-attached external KVM to control it from the JetKVM web UI.

I've been a professional software developer for over 15 years, but this is the first time I've used Go. So, I used Mr. Tuttle's Tailscale plugin as a starting point for my own. It was relatively easy to whittle off the Tailscale-specific stuff before adding in my own functionality with the serial library.

I've shared my work here: MaffooClock/jetkvm-plugin-serialkvm

---

I've been fairly successful, I think, despite my n00b status with Go. However, I've reached a point where I'm just stuck, and I haven't been able to figure out how to get past it. I'm hoping someone might be able to point out whatever I'm missing so I can get back on track.

This is what's in /userdata/jetkvm/last.log when enabling my plugin:

2025/02/03 14:57:57 Status from process manager: stopped
2025/02/03 14:58:00 Reconciling plugin serialkvm running , should be running 0.0.1
2025/02/03 14:58:00 Started plugin serialkvm version 0.0.1
2025/02/03 14:58:00 Status from process manager: running
2025/02/03 14:58:00 Starting process: ./serialkvm
2025/02/03 14:58:00 Accepted plugin rpc connection from @
2025/02/03 14:58:00 Plugin rpc server started. Getting supported methods...
[jetkvm-plugin-serialkvm v0.0.1] 2025/02/03 14:58:00 rpc client started
2025/02/03 14:58:00 Plugin has supported methods: [getPluginSupportedMethods getPluginStatus switchInput]
2025/02/03 14:58:00 Status from process manager: running
2025/02/03 14:58:00 Status from process manager: running
[jetkvm-plugin-serialkvm v0.0.1] 2025/02/03 14:58:01 config file doesn't exist, using default

...which all seems right to me. So far, so good.

Now, there's not yet a way to configure my plugin -- I see a "Plugin configuration coming soon" message in the plugin modal, and I know the final bullet in PR #10 says configuration management would be in a separate PR. Cool, no problem. I can manually supply a JSON configuration file for my plugin for testing, so it's not a barrier for my own development and testing.

My plugin is implements a DoSwitchInput() method, called when JSON-RPC gets a request for switchInput. Since there's not yet a way for a plugin to add it's own components to the web UI, the only way I know of to test this would be to manually dispatch a JSON-RPC message.

So here's where things get sticky (for me)...

I initially assumed that the web UI used a WebSocket connection or maybe just a HTTP API for communicating with the jetkvm_app process, and that process used the Unix socket to the plugin to relay whatever was sent from the user's browser. I did not investigate this at all, I just made the assumption. 🤦🏻‍♂️ After wasting a lot of time trying to "test" JSON-RPC requests, I finally figured out that I was way off in left field. I won't even tell you how I was doing it because it is quite laughable how far off I was, haha. But it was a reasonable guess, and I had to start somewhere, however self-misguided it was.

After taking some time to actually look at the JetKVM source and make an attempt to understand how it works, now I understand that the web client is using a data channel on the WebRTC session as the transport for JSON-RPC. Damn. I mean, neat! But also... damn.

All I wanted to do was just manually fire off some JSON-RPC requests to test my Go code, especially since there's not currently a way for my plugin to inject components into the web UI (like, a dropdown in the action bar). Now I know it's not as simple as using curl or anything similar to dispatch these JSON-RPC payloads.

So, uh... how now brown cow?

So how would I send JSON-RPC requests for testing? I looked at trying to whip up a Node.js script to setup a WebRTC session so it could grab the data channel JSON-RPC, but that's already proving to be quite complicated. This is turning into a "the juice ain't worth the squeeze" situation, except I really would like to test JSON-RPC requests.

Or am I looking at this in completely the wrong way? Is there another way to test that my plugin will correctly receive and handle a JSON-RPC request for my switchInput method with a inputID parameter without actually sending such a request?

[tutman96]

So you'd need to implement two rpc handlers, one for the browser side (data channel) and the other for the plugin side. Then you'd need to figure out how to plumb them together such that the browser RPC knows which plugin to send the request to.

[MaffooClock]

I had kind of the same thought, I think. I figured I could fire up a second plugin (not necessarily the only way to do it, just makes it easy to deploy and cleanup, I guess) that listened on a particular TCP port (perhaps HTTP or even WS), that connected to the JSON-RPC in the backend. But I'm not smart enough in Go (at the moment) to figure out that backend connection. I'm guessing the plugin's socket is part of that solution.

---

Incidentally...

I won't even tell you how I was doing it because it is quite laughable how far off I was.

I guess I'll just say it, heh. This strays from your comment a bit, though.

I started an SSH tunnel that connected a local TCP port to the plugin's socket file:

ssh -N -L 12345:/userdata/jetkvm/plugins/working_dirs/serialkvm/plugin.sock root@jetkvm

...and was using echo to pipe a JSON payload through that tunnel via netcat:

echo -n '{"jsonrpc": "2.0", "method": "switchInput", "params": {"inputID": 3}, "id": 1}' | nc localhost 12345

I eventually figured out this was incorrect, but there was enough of a response that it kept me stuck on it. As soon as I'd hit ENTER on that echo command, I'd instantly get two JSON objects:

{"jsonrpc":"2.0","method":"getPluginSupportedMethods","id":1}{"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":1}

...the first looked like it was echoing the request (which is not what I sent), and the second looked like a response.

And in last.log, I'd see:

2025/02/03 15:23:55 Accepted plugin rpc connection from @
2025/02/03 15:23:55 Plugin rpc server started. Getting supported methods...
2025/02/03 15:23:55 Failed to read message: EOF
2025/02/03 15:24:00 Failed to get supported methods: &{-32603 Internal error timeout waiting for response}
2025/02/03 15:24:00 Plugin has supported methods: []
2025/02/03 15:24:00 Plugin does not support getPluginStatus method

So, somehow my erroneous attempt to write to a JSON-RPC request directly to the socket resulted in something triggering a null payload (I'm guessing, hence the EOF and subsequent timeout). I eventually figured out this was the wrong way to go about what I was trying to do, but it makes me think I was close... like, perhaps the payload needed to be send encoded rather than as plain text (except I was getting back plain text, so...). Oh well, more red herring that I should stay away from.

Thank you for chiming in 👍