Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Dynamic Config Provider #82

Merged
merged 42 commits into from
Aug 22, 2023
Merged

Conversation

newhinton
Copy link
Owner

@newhinton newhinton commented Apr 3, 2023

closes #63
closes #86
closes #101

@newhinton newhinton changed the title Feature/noid/configjson [Feature] Dynamic Config Provider Apr 20, 2023
@newhinton newhinton added this to the 2.2 Provider Update milestone Apr 20, 2023
@newhinton
Copy link
Owner Author

@gilbsgilbs If you want to take a look at this PR, i have now switched a lot of remotes to the new dynamic way. Though there are a lot of missing features and rough edges, so it is not recommended to install it on an actual device.

@gilbsgilbs
Copy link

Ack. I'm very busy right now, but I'll try to take a look at a non-deterministic point in time.

Copy link

@gilbsgilbs gilbsgilbs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, this adds support for "generic" providers, but at the moment, you cannot add them all from the UI. The list is limited to the providers declared in the provider_ids array. However, they should still be usable thanks to the import feature, is that correct?

Overall I think it is a fantastic and very useful work. The implementation is rather concise and reads better than I anticipated. Here are some general remarks (I'm sure you're aware of most of them as this is still a WIP):

  • I had a build error (related to de translations), but removing those values worked around it. Rebasing master and bringing back CI workflows should make that apparent.
  • As you said here, the amount of configuration per provider is indeed kind of overwhelming. I think this could be very much improved by putting "advanced" options in a separate tab or in a collapsible menu. But another PR for this is fine I think.
  • As noted in a comment in your code, dark mode is not supported yet.
  • The dropdown options are very small. It's easy to missclick if you have fat fingers.

Regarding translations, my experiments with deepl.com have been fairly impressive, and I've yet to find an completely incorrect translation. With some pre/post-processing, it could be a decent starting point before relying on the community. Their API free-tier allows 500k characters/month. There's currently ~130k characters to translate.

app/src/main/java/ca/pkay/rcloneexplorer/Rclone.java Outdated Show resolved Hide resolved
input.setPadding(padding)
val items = ArrayList<String>()

option.examples.forEach { example ->
Copy link

@gilbsgilbs gilbsgilbs Apr 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's smart to use examples for dropdowns, however, I'm unsure this covers all the cases. RClone still allows specifying arbitrary values for options with "Examples". For instance, s3 backend has many endpoint options with examples, but may you roll out your own S3-compatible storage such as Minio, in which case you'll always want to specify a custom endpoint. Still, it's unclear to me if specifying arbitrary values for those is actually useful in practice ⬇️

"Examples" (resp. "Options") sometimes include a Provider field, which defines a syntax allowing to restrain an example (resp. an option) to a specific set of providers. Let's take the same s3/Minio/endpoint as an example:

  • The backend is s3
  • This backend has a provider option, with Minio as one of the examples, therefore the dropdown for this option will include Minio (this is already implemented by this PR)
  • Then there are multiple endpoint options declared by RClone:
    • one with "Provider": "AWS" with specific endpoints examples for AWS
    • one with "Provider": "ChinaMobile" with specific endpoints examples for ChinaMobile
    • … so on with other providers …
    • one with "Provider": "!AWS,IBMCOS,…,ChinaMobile,…" (i.e. not any providers that was previously defined), which doesn't provide any example

So with our Minio example, we're in the latter case. If "providers filtering" was implemented, it would just display a text field and not a dropdown in this case, because the only endpoint option that matches our Minio provider has no examples. So it would be fine. If I'm not mistaken, with the current implementation, it will just display many endpoint dropdowns and one endpoint text input, and I'm not sure what's the behavior when passing this to RClone.

All in all, there might be niche use-cases where specifying arbitrary values for options with examples might be useful (such as using a new S3 region/endpoint for a given provider that is not implemented in RClone yet). But IDK, it might just not be worth thinking about it for the moment. However, I do reckon providers filtering should be implemented at some point.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is exactly the kind of stuff where i wil slip with this, because i cannot extensively test every remote.

Thanks for the writeup, i will have to read this thoroughly to make this work properly, especially to prevent weird behaviour with rclone

Log.e("TAG", " Opt: ${it.name}")
Log.e("TAG", " Opt: ${it.type}")
when (it.type) {
"string" -> {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, just for the sake of completeness, here are the types where the UI could be improved by using dedicated components:

  • bool, which should be a checkbox (there's also one boolean type, but I think it's a bug in RClone)
  • int, which could include some type validation
  • SizeSuffix, which could be implemented by specifying a textbox + a "scale" dropdown, and validating that an integer was typed in the textbox
  • Duration/Time, ditto or, optionally, a clock
  • RFC 3339, with a clock+calendar popup
  • MultiEncoder, which could be a multi-select box (but this one is probably niche-enough that we shouldn't bother)
  • SpaceSepList, which could be multiple text-fields with ➕ and 🚮 icons (also kinda niche)
  • Time/unixtime/decimal number/Tristate/hexadecimal/octal, unix style/filename not widely used

But that's probably fine as this in a first implementation.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is some wild stuff in there :D I guess i start with the obvious ones, bool and string are implemented, and i most certainly will implement int aswell. The other-ones will probably have to default to text input, the user has to figure out what input needs to be made :D

@newhinton
Copy link
Owner Author

but at the moment, you cannot add them all from the UI

Yes. At the moment those are hardcoded, but in the future i want to try to get rid of that aswell, so that everything is "dynamic".

"advanced" options in a separate tab or in

Good idea!

Regarding translations, my experiments with deepl.com have been fairly impressive, and I've yet to find an completely incorrect translation. With some pre/post-processing, it could be a decent starting point before relying on the community. Their API free-tier allows 500k characters/month. There's currently ~130k characters to translate.

I am a bit on the fence with this idea. Generally i want to refrain from implementing a solution specific to this app, and i also would need to figure out if i am even allowed to use it. (I might want to monetize this app on the play store, so i need to be careful.)

My dream-goal would be for the rclone project to implement translations natively, and then we dont have to deal with that twice. I already opened a ticket for that, but i am afraid that will take quite a while. But generally speaking, translations in this app are going to be complicated to pull off properly.

@newhinton
Copy link
Owner Author

So let me say thank you! I did not expect such an in depth review, and i am glad you are looking at it! There is lots of great suggestions and i will implement much of it, so that this will make this app easier to maintain and use in the future.
Thank you!

newhinton added 5 commits May 29, 2023 15:40
# Conflicts:
#	app/src/main/res/layout/config_form_template_text_field.xml
#	app/src/main/res/layout/config_form_union.xml
#	app/src/main/res/layout/remote_config_form.xml
#	app/src/main/res/values-de/strings.xml
#	app/src/main/res/values/arrays.xml
#	app/src/main/res/values/strings.xml
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
@newhinton
Copy link
Owner Author

Good news! The dynamic config editor will allow rudimentary editing of remotes! Though i will need to test this thouroughly, especially if values are secret. They break if not reentered at the moment.

@newhinton newhinton merged commit 297f42b into master Aug 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for Base32768 encoding in crypt backend App Crash on Import Configuration-As-Code
2 participants