As rclone user I believe that the construct to use pseudo-remotes (I faced this with crypt some time ago) is complex for users. And the concept is being extended with cache / chunker / union?
and perhaps the zipper one ... (sending a folder with many many small files to a remote is a PiTA9).
The config file becomes clumsy and uneasy to understand.
As an example, read the following topic in the forum - Encrypted chunker
Perhaps time to rethink architecture/UX on this. I see two different building blocks but could be some more, and other alternatives.
a) using a kind of piping paradigm, user needs to specify end remote and the piping. the intermediate steps are transparent for configuration etc.
b) config file should pack around the end remote all needed information, not needing to have sparse pseudo-remotes detached from end remote configuration.
Piping should be logic. So, should we recommend encrypt then chunk and do not chunk then encrypt or otherwise?
As I am just a user, dream is easy to me...
a) a remote is a remote. So, one needs credentials for the remote.
b) I can be able to write in clear in the remote or encrypted
c) I can be able to write/read as my file system shows (folders/files) or write/read chunks. A chunk might be just a small piece of a big file or a packing of small bits. How it is the translation of the remote chunks to the "filesystem" I see as user, is just magic
I can comment for example an application called CarotDav. You can read/write in clear or encrypted to a remote. You just select yes/no to encryption and of course provide the key. It uses a convention: in the remote all files/folders starting by a given string have their names encrypted and their contents.
config file... I either edit it with a text editor (when I can) - or use interactive session for remotes that need OAuth. For me is a nightmare having a remote1 that is a real remote and remote2 that just points to remote1. The "blob" for each one is so different... Moreover, if you change the name of remote1, remote2 will lost track of its chaining (it happens with config edits, when a remote is renamed....).
So, I would keep a section for just one remote, and would accomodate in an specific structure all "middlewaring" options, keys, etc.
As user of rclonebrowser, I would love to see a GUI for the config of remotes, where I could switch graphically on/off encryption, etc for each remote. Even to configure remotes using a nicer UX.
Perhaps it could be built a on the spot translator from rclone.conf classic to rclone.easy.conf without the need to rewrite rclone... Config sessions could be dettached from the main code of rclone so that rclone could concentrate in log in/out, upload and download....
Something like... when you do rclone config to make a new remote (let's say a google drive), at the end it asks you whether you want it encrypted/chunked/etc.
Rclone then runs you through the config for the crypt/chunker etc and renames the original remote.
This process could then continue with chunker if you chose crypt (or maybe the other way round).
So the config file would end up with 3 remotes, but the user would see it as a single config session.
What do you think?
The other idea I has was wrapping the chunker remote with a flag --chunker say. So you could use it (with a set of sensible defaults) with any remote. You could use --crypt the same way, but having to configure the passwords etc in advance would make it too annoying.
yes, a rclone wizard,
it starts out high level, asking what you want to. encrypt, chunk, plex, mount, etc...
then ask for the detailed info like providers, username, password and so on.
then create the needed config file and remote.
for the provider, do a ls command or some other basic test.
for a complex setup, with encryption and chunker,etc.. copy a test file to local to dest, then copy that test file from dest to local and compare md5.
with plex, i know that @Animosity022 has optimized settings/templates. there could be a couple of pre-set plex configs, and if someone had chosen plex1 - optimized for high bandwidth , and had problems, then end-user could easily switch to plex2 - optimized for low bandwidth and latency issues.
you could set the plex settings in the config and override it with flags.
there would be a flag for each plex settings, plex1, plex2...
in that way, a plex user can quickly optimize their setup. rclone --plex1