Closed grantseltzer closed 7 years ago
On the other hand, caching directory contents would lead to inconsistencies.
It definitely has challenges, but what inconsistencies do you have in mind @satori?
I think this is a great idea except for the caching. It could be very similar to sftp
, which is completely interactive. Normal commands work with remote (in this case Dropbox) files and there's a few modified commands (e.g. !ls
, !pwd
) to work with local files. AFAIK sftp
doesn't use caching; commands that list files/folders refetch every time.
Perhaps caching is the incorrect way of solving the issue I had in mind of fixing speed of use. Perhaps some way of 'establishing a connection' I assume authentication is done on a per-command basis. Dropbox api might not support it, I haven't looked into it all, probably would be more work on the sdk rather than dbxcli, if it's even wanted.
Interactive mode can certainly be done easily if there's demand for it.
Hey everyone, right now I don't see this use-case as a good fit for dbxcli. Feel free to reopen or file a more specific request as appropriate.
I wanted to share some thoughts and open a discussion about an interactive mode for this project.
The way I picture it:
dbxcli --interactive
ordbxcli -i
would enter a repl like environment with a prompt that would allow the user to just enter commands. There could be an exit command to leave the mode.This alone I don't think is a huge improvement on convenience. If there were some type of cache to store information such as directory contents then there would be a huge improvement to speed/ease of use especially with Go's built in concurrency features. This would also allow for implementation of features such as
cd
since thepwd
could be stored in memory.