Feature Request: Client/Server Design for Multiple Systems and Processing Offloading

[TephlonDude]

In order to make this a useful tool across multiple systems, it would be nice to have a server side which collects the screenshots and does the processing and a client side which grabs the screenshots and either caches them (if the server is unavailable because you are away from your "home" network) or sends them to the server.

This would allow you to potentially work across multiple systems and have everything integrated into one UI. It would also allow alleviate the processing overhead on the system that is being recorded and moves it to another location, minimizing the impact on the system that is being actively used.

[eylles]

Took a glance at the code, the logic to process the images is part of the record screenshots thread right after image.save

Perhaps a way to achieve the client daemon separation would be by running the processing of the screenshots in a separate thread that is constantly listening to another ip:port.

Could be called something like screenshot_processor on a full local mode it would be say localhost:8083 (as an example) while on client or daemon mode the ip and port would be configurable, as for the data it recieves could be some metadata header like the screenshot name and time of capture, then the screenshot itself, once it has the screenshot fully transfered (if not runing local) it will process the screenshot and answer through the port a cobfirmation the screenshot was processed and that it can recieve another one.

However that does create the problem of sending past screenshots, so to handle that there could be another thread called something like screenshot_sender that would be monitoring connection to the port, so if connection is lost and it did not recieve a confirmation of processed screenshot it marks the screenshot as not sent and adds it to a queue (maybe even just append to a list), once it gets connection to the prot and confirmation the other process can recieve screenshots start sending them from the beginning of the queue.

As for the search interface it should remain on the client side but make requests to access the server side data... and that is where stuff begins getting complicated.

[koenvaneijk]

I like the core of this idea, however I would like to avoid introducing too much complexity at all costs, as complexity would reduce the (reasonable) auditability of the code and could introduce security risks. It will also require significant more security efforts to secure the server at the exposed port.

Could you give an example of a use case when working on multiple machines and requiring access to OpenRecall history of another machine (without having access to that machine)?

[TephlonDude]

Here is a scenario that I see would be beneficial having a client/server model. You want to make openrecall available to everyone within your company. Unfortunately, the hardware the users are using on their desktops is relatively low end. The time and effort to upgrade the hardware to support openrecall would prove to be too disruptive to the users and the up front cost of such an upgrade would not be in the budget.

But, if there was a relatively light weight client on the desktop that could push the screenshots to a beefier server with GPU access, this would eliminate the need for the workstation upgraded. Furthermore, the server would not have to be an on premise device. Rather, it could be a cloud based server that performs the processing and the system utilization time is paid for on a monthly basis. This moves the cost of the server out of capital costs (which are often harder to get funding for) into operational costs (which are more easily justifiable in a business budget).