Headless Linux version

[MeestorX]

Jumping off from here...

I would like to see a headless version of aes67-monitor. The UI is already browser based, and the commands are all rest-based, just have to remove the need for electron.
I'd help, but I'm not completely clear on what part(s) electron is doing that need to be re-written.

[philhartung]

Thanks for opening this discussion!

Currently, the internal process structure with Electron looks like this:

To run AES67 Monitor in headless mode, we would need to refactor the backend into a separate process that operates independently of Electron. Instead of relying on Electron’s inter-process communication, we could utilize WebSocket communication as an alternative:

What needs to be done:

• Backend Separation: Refactor the backend code into its own library, making it usable both by the Electron app and the headless service.
• Communication Layer: Implement an optional WebSocket communication layer to handle interactions when running in headless mode.
• Headless Service: Create a headless service that launches the backend and runs an HTTP server to serve the frontend and manage WebSocket communication

[MeestorX]

Thank you for clarifying!

So, main.js is the backend and app.js the front end? Would building ws communication between those 2 be the lion's share of what needs to be done? Of course a webserver to serve the vue frontend of course, but that's trivial.

[philhartung]

No, I believe the bulk of the work will involve refactoring main.js to fully decouple the backend from Electron, as well as making the frontend communication pluggable—so it functions with both WebSocket and Electron IPC.

[philhartung]

I would prefer to implement the headless mode myself. Regarding the timeline, this will definitely happen after the 1.0.0 release. Currently, two bugs are blocking the 1.0.0 release which need to be resolved, and I would like to sign the macOS binaries for the final 1.0.0 release, so issue #14 needs to be resolved as well. After the 1.0.0 release I would consider this the highest priority now

[MeestorX]

That suits me fine, as you've done a brilliant job so far. Much easier than me messing up your code! :-)

[HSteindl]

Hello!
When you think about implementing WebSockets or similar maybe you would want to go full-circle and offer this very interface as a Websocket-API ?! I can think of many applications, where one would leverage the SDP and/or audio backend for building custom made monitoring apps or similar. No matter how beautiful your FrontEnd GUI will be, it will always need to be generic (for lack of a better word).

[MeestorX]

Hello! When you think about implementing WebSockets or similar maybe you would want to go full-circle and offer this very interface as a Websocket-API ?! I can think of many applications, where one would leverage the SDP and/or audio backend for building custom made monitoring apps or similar. No matter how beautiful your FrontEnd GUI will be, it will always need to be generic (for lack of a better word).

Fully agree. I think the most common use of this code would be implementing it into some larger app. Personally, once I start a stream, I wouldn't need to look at the UI again. And in fact, for my purposes, after the initial startup, I don't need to see the UI again. On subsequent restarts, I would want the last stream selected to start automatically, without having to open the UI at all. Or I might want to filter the list to see only certain streams - there's no way for you to predict how this might be useful, so don't spend your efforts on "covers all situations" UI, then others can add functionality as needed.
A websocket API would be just the ticket for that. :-)

[philhartung]

There will definitely be some form of WebSocket API available when implementing the headless service. If we want third-party software to be able to use it effectively, it's especially important to properly document the API — after all, no one can use an API if they don’t know how it works.

[MeestorX]

Have you been able to make any progress?

[philhartung]

As mentioned previously, the current priority is completing the 1.0.0 release before I begin work on implementing headless mode. All known bugs have been resolved, and the only remaining blocker for the 1.0.0 release is signing the macOS binary.

I haven’t had much time to dedicate to the project over the past few weeks, but I’m aiming to pick up the pace again in July.