Big Thanks and a discussion about Job Architecture

[infinitehope2025]

First off, I want to give a huge thanks to the Dev for creating this app!

I've been using rclone for many years via the CLI and I've always wanted a GUI dashboard to monitor my remotes and job statuses. There have been a few attempts over the years to create a GUI for rclone, but nothing really met my needs. Also, recently, a couple of closed-source paid apps have popped up, and while I don't mind paying for good work, I'm not interested if they aren't open source. Rclone Manager therefore seems to meet my requirements and has so much potential if the Dev continues to develop it.

Now for me, the most important feature that is currently missing (and unfortunately will probably stop me using the current version of Rclone Manager) is the lack of support for multiple running jobs.

This was asked and confirmed by the Dev here:
https://github.com/orgs/Zarestia-Dev/discussions/181

Just to add to that discussion (apologies for starting a new discussion), I suggest the architecture covers the following:

• Re-think the use of Profiles. Currently they define source and destination remotes and are used kind of like a job;
• Add a separate object (with dedicated modals) called "Job": a Job references source and destination Remotes and specifies parameters for that Job including the main action i.e Sync, Copy etc;
• Change the current "Job" type to "Process" (or something similar) - Jobs currently refer to things that are running (like Syncs), so "Process" might be a better name, and would be separate to Jobs;
• "Scheduled Tasks" appear to be tightly bound to a Remote (i.e. they are defined under a Remote) - make it a separate object that references a Job and adds cron (or other triggers) parameters;
• Each of the object types (Job, Scheduled Task, Processes) would have their own dedicated sections within the app's interface and not necessarily be so tightly integrated with Remotes.

To summarise: Jobs define a specific action between source and destination remotes (eg Syncing), Scheduled Tasks define when to run a Job, and Processes show the current status of running Jobs.

With something like the above defined, along with the relevant controls for each object, Rclone Manager could allow many Jobs to run simultaneously and the dashboard interface would provide true at-a-glance monitoring.

And I think many rclone veterans (as well as new rclone users) would prefer to use Rclone Manager as their main tool for running rclone jobs.

[Hakanbaban53]

Thanks for the kind comments and ideas. I really like these suggestions! First, changing the job type to "Process", this actually exposes the backend behavior to the end user. I hadn't converted it to a more user-friendly name before, but Process will work well.

Scheduled Tasks are currently highly coupled to remote settings or profile settings. I ended up binding too many things together, everything in RClone Manager became tightly linked. When I started coding, I didn't anticipate the app needing such complex actions; I only planned for the basics like mount, sync, and move. As it grew more complex, I started seeing the drawbacks, for example, when a user creates a new remote, they need to reconfigure everything: vfs, sync, and so on.

Now I'm thinking about building a more advanced Scheduled Task editor, or a direct task editor with drag-and-drop (I actually have a complete concept for something like that). However, since the app's core is so tightly coupled, I probably can't fully separate everything, but I can improve the experience for both basic and advanced users. It won't be 100% perfect, but it will be good enough to get the job done.

[infinitehope2025]

Thanks so much for the detailed explanation, and yes, I know ... many times when you start with a simple concept then it grows and grows!!

I'm glad you're already thinking of a solution, even if it isn't a complete redesign of the core. If you can get most of it working, supporting multiple running jobs, that would be fantastic! I'm really looking forward to seeing what you come up with :)

Who knows, your app might eventually become very popular with the rclone community and you might then want to take another look at the core when you have the time and motivation to do so in the future