I will try to explain this the best I can.
The idea is to enable the delegation of the token-refresh procedure to other applications. When a token expires, rclone should re-read the configuration file (in search of a new valid token) before starting the token-refresh procedure. In this way, if a new valid token is found in the configuration file, rclone would not need to to use the built-in token-refresh cycle.
I like this idea! I am currently using custom scripts that provide rclone with fresh tokens for ACD, but have to restart rclone every time the token expires.
However, I think a more direct approach to providing rclone with tokens would be preferable. A flag like --acd-token-refresh (--gcd-token-refresh, …) that points to an executable that hands out new tokens and that would replace the build-in token-refresh cycle would be a perfect solution for me.
Hi @semafoor,
you say an executable that echoes the new token?
I wonder what @ncw thinks about these ideas 
Yep, that is what I mean! If such a flag existed it would also be easy to write an executable that echoes the token that is currently in the configuration file to cover (±) your request too.
I’m not sure if many people would find such a thing useful; I’m glad to see that at least I’m not the only one ;-).
I think the feature is good. It decouples the token refresh (generation?) from the application.
Let’s see what others think bout it.
I have mentioned this as well since day 1 on two seperate threads - even someone can “hack” the existing code and instead of rclone executing the refresh function, it should execute the “reread” token from file function. Shouldn’t be hard for @ncw to make the change. Maybe he can even give us a “patch” in this post so we can do the changes and compile on our own…
A option to token management… Oh, it’s a good thing to hear. I’m just looking forward to something like it.