Configuration-As-Code

[newhinton]

Currently the ui for configuring remotes is done on a per remote basis, requiring a lot of work.

Instead, i should implement a json-format that can be read by a generic ui, that allows to display the available options. This would allow for easy addition of new/changed config items.

A "guided" config would also be preferable. Eg in each configuration gets it's own page.

Questions: how to deal with images and translations?

[gilbsgilbs]

I strongly emphasize with this idea. I always found it a bit sad that RClone Explorer and RCX weren't able to fully empower what makes RClone shine: abstraction. It handles all remotes in a completely generic/unspecific manner, which this app could completely take advantage of. Not only it makes it cumbersome to add a new remote, it also increases maintenance cost.

FWIW, RClone is able to serve a web-based GUI that does exactly this: https://rclone.org/gui/ (which AFAIK is this UI). And obviously, RClone itself does exactly this when using rclone config.

Questions: how to deal with images and translations?

Regarding images, I think it's fine if most remotes don't have an image. We could focus on providing images for the most frequently used remotes, and just rely on the first letter of the remote names to provide a dummy "logo" in the listing when we don't have one. However, there's simple icons that provides colorless SVG logos of many brands. Maybe we could source some from there.

Regarding translations, I think the most straightforward way would be something as follow:

• Export providers configuration from rclone with rclone config providers (this step will probably be needed to implement the feature anyways)
• Write a script that extracts "Help" and "Description" keys from the previously generated config to a dedicated string resource file.

A template could be used as the name of the exported strings (such as rclone_help_uptobox_access_token, where access_token is the name of the option, and uptobox is the name of the provider, or rclone_description_union which would be the description of the union remote), so that the translated string could be retrieved easily. That'd make 51 description + 1324 option strings to translate (at time of writing), which seems like a lot. Maybe we could focus on non-advanced options in a first draft, which reduces this number to "just" 51 + 233 strings. Maybe RClone folks could also be interested in i18n for providers, which would help gathering efforts.

It's also worth noting that most frequently used providers (such as the ones already implemented) should probably appear first in the providers list. Other esoteric remotes (such as Union or Mail.ru) could be proposed in a collapsible menu just below. A search bar could also be helpful if there are lots of providers to pick from.

[newhinton]

FWIW, RClone is able to serve a web-based GUI that does exactly this: https://rclone.org/gui/ (which AFAIK is this UI). And obviously, RClone itself does exactly this when using rclone config.

Ugh it would be amazing if this would already be included in the rclone-lib. Though to make this work as i want to, it would need theming, "stripping" and a better mobile navigation. None of those are supported sadly :/

I think it's fine if most remotes don't have an image. We could focus on providing images for the most frequently used remotes, and just rely on the first letter of the remote names to provide a dummy "logo" in the listing when we don't have one

Good idea. I always wanted to try to fetch favicons if possible, so this would further reduce the need to have every icon!
Also there is a SimpleIcon Java Port which i probably can integrate easily.

That'd make 51 description + 1324 option strings to translate

Yikes. I feared something like this. I dont think there is any reasonable way to actually translate that.

Also it's not quite what i initially meant. I'll explain in a short while.

My current draft implements a "normal" activitiy based ui just like we have now. But instead of predefining each option, textfield and whatnot, i generate a function that can generate those inputs "on-demand". So if i select a webdav-remote as an example, we would instanciate a "webdav-config-list" which contains a list of type,name,option,etc which will be used to generate the ui.

The benefit: We only have to edit a relatively simple list to add/edit options, while keeping the ui in one "simple" config-ui.
It is still a lot of work to maintain though.

On a second thought:
There is rclone help backend x
I need to find out if that one is machine-readable. If it is, we can auto-generate everything on the fly. No manual maintenance needed anymore! Lets hope i can make that one work :D

[gilbsgilbs]

I dont think there is any reasonable way to actually translate that.

In the meantime, I don't think it's that big of a deal if some options remain in english. But I guess AI-based translation services can do miracles nowadays, that may be another option.

On a second thought:
There is rclone help backend x
I need to find out if that one is machine-readable. If it is, we can auto-generate everything on the fly. No manual maintenance needed anymore! Lets hope i can make that one work :D

You lost me there. I think rclone config providers is exactly what you're looking for, and AFAIK rclone help backend x is basically generated from this metadata. rclone config providers is indeed "machine-readable" because it's bare JSON. IIUC, this just does what you initially planed to do with "manual" config options, except it's already built-in RClone and completely automated. There may be some UX challenge to integrate this and make it look user-friendly, but still, I think it makes 90% of the job.

For instance, you can get all options for PCloud provider through:

$ rclone config providers | jq '.[] | select(.Name == "pcloud")'
{
  "Name": "pcloud",
  "Description": "Pcloud",
  "Prefix": "pcloud",
  "Options": [
    {
      "Name": "client_id",
      "Help": "OAuth Client Id.\n\nLeave blank normally.",
      "Provider": "",
      "Default": "",
      "Value": null,
      "ShortOpt": "",
      "Hide": 0,
      "Required": false,
      "IsPassword": false,
      "NoPrefix": false,
      "Advanced": false,
      "Exclusive": false,
      "DefaultStr": "",
      "ValueStr": "",
      "Type": "string"
    },
    …… [ and so on ] ……

What I was suggesting in my previous message was actually to use this output to provide a generic way of supporting all backends, just like rclone config or the webui do.

[newhinton]

You lost me there. I think rclone config providers is exactly what you're looking for,

Okay now i feel stupid. Thanks, that is what i am looking for!

I never really did a deep-dive in ALL the capabilities rclone provides, so this was new to me. But this will work fine, albeit actually fully implementing this will take quite a bit time!

Edit:

What I was suggesting in my previous message was actually to use this output to provide a generic way of supporting all backends, just like rclone config or the webui do.

And i will do exactly that ;) Thanks for the great input!

[gilbsgilbs]

If you need assistance, feel free to reach out. I can't guarantee I'll spend many time on this, but that's something I've been willing to contribute in RCX for a long time. I never found the motivation because RCX had turned unmaintained, and I felt overwhelmed by the work needed to bring the project back up and on the path I wanted.

Okay now i feel stupid.

You're certainly not, and it is not what I wanted to imply by any mean 😅.

Thanks for your work on extRact :) . Very much appreciated.

[newhinton]

So, i have now a working prototype.

There are two problems i see with this:

1. Translations
   There are no Translations, and we cannot really provide our own. See here: rclone#6909. That means everything will be in english.
2. Overwhelming Customizability.
   For some provider, there are a LOT of options. Finding a specific one might be hard, and the ui is not up to the task.

I am open for ideas on how to improve this!
Also, i am very interested in people testing those changes!