I've been experimenting with ways to extend the Opus scripting API to other languages. One approach that’s been working pretty well is using local servers to exchange data (kind of like a simple/rudimentary IPC).
The downside is that since everything goes through the Windows TCP/IP stack, it inevitably adds some latency. It can also run into issues with stricter security software.
A nice way to improve this would be if HttpRequest supported Unix sockets (using .sock files). That way, in a local setup, you could get almost zero latency and much smoother communication between the server and Opus (in this case as the client).
The downside is that since everything goes through the Windows TCP/IP stack
I wasn't sure about it, but according to AI, the TCP/IP stack is indeed still used even when all communication happens on the same machine.
it inevitably adds some latency.
I don't think the overhead from using the TCP/IP stack matters. The latency is mostly coming from context switches. There isn't much code that needs to be executed anyway when you send bytes between two local processes.
I think the real advantages are:
It can be more firewall-friendly, but I haven't checked.
Unix socket file is unique. There will be no conflict with other SW. Port can already be used by another process.
A nice way to improve this would be if HttpRequest supported Unix sockets
Honestly, I would be surprised if Microsoft added this feature to their more than 20 year old component.
It's not a huge overhead, but if you plan to, e.g. send and receive several messages between the two on a regular basis, you can notice the difference. I guess this is also somewhat system-specific. At least in a quick test I did with Python, there's an overhead for each message ranging from 10 ms up to 100 ms (the higher values are probably due to the ESET firewall also affecting this).
True. Thanks for pointing that out.
On this one I'm kind of lost, honestly. I was talking about implementing it here. I don't think that's using the same component that exists via COM object (if that's what you're referring to), but I might be wrong too.
At least in a quick test I did with Python, there's an overhead for each message ranging from 10 ms up to 100 ms
Interesting. I remember I tested the performance of GRPC over TCP/IP, and a single method call would take 1-2ms.
I think something else is going on. But still adding support for UNIX files is good.
Hello Jon. It's totally up to the user; it should work as an IPC to communicate with Opus. In my example case, I built a Python script that runs a server, and then Opus can communicate with it to send/retrieve different kinds of data. This is useful p.e. for delegating tasks that Opus can't do natively, or that can be done much faster in another language.
I was about to upload an example script (not using .sock, but regular connections).
EDIT: Uploaded. It's just a simple Color Picker that does all the heavy lifting in Python; Opus just requests the results on a timer based on the current mouse position and show the results. The main idea is, of course, to extend Opus capabilities.
Hopefully we can test here how different security software reacts to scripts that create their own server. In my case, ESET doesn't have a problem. My guess is that with Unix sockets this could be less of an issue, but I'm not sure.
Another thing is that the Opus script requests data every 100 ms. With Unix sockets, we could probably poll every 10 ms (since there's no event in the Opus scripting API to detect mouse movement).
Here's a quick test script I made for testing.
You need at least PowerShell 7.0 and .NET 5 or later (since it uses UnixDomainSocketEndPoint).
It's a very basic test script that just asks for the time.
(I was planning to test with a more proper example in Python, like a color picker 2.0, but I just noticed that AF_UNIX isn't implemented at all in the Windows version. And if you use non-Windows builds, you can't directly use ctypes.windll. But that's totally unrelated to Opus.)
