Hello @ncw! Thank you for merging PR 2844, adding vfsgen for static items!
Here is a question: how should we deal with static assets?
For example, we may have a file called “styles.css”, and normally, that might be served via /static/styles.css. However, this would make it impossible for a user to browse a folder named /static (!!)
Here are some options:
Choose a sentinel value for static assets. For example, “/rclone-static-112358” or “/random-number-11235”. Downsides: now we have a hardcoded value which a user is never able to browse.
Inline everything. That is, rather than our code saying <link href="/rclone-static/styles.css">, simply inline it. The two disadvantages is that this does not work for images (for example, an icon depicting a folder), and this would increase the HTML payload size upon every request. (Technically, one could inline .svg files.)
Choose not to use any HTML features which rely on static assets, such as images. This could be very limiting.
Host assets externally (eg, <link href="http://example.com/styles.css">). I think this is the worst idea, since how rclone’s http feature would have an external dependency, which has both stability and security implications.
Run another local HTTP server, on a different port, whose sole job would be to serve static assets. Eg, <link href="http://localhost:9090/styles.css">. This would give the most flexibility, though probably has the most complexity.
If it were me, I would probably choose option 1, or possibly option 2, or option 5. But maybe you have an idea for a solution I haven’t thought of, or a tradeoff that you’d find acceptable.
A good question indeed! I was thinking that we could use a special directory like @rclonestatic@ and keep them all in there.
Another way of sorting this out would be to use a parameter string so append ?rclone=static to each URL and get the URL handler to separate them. This would have the advantage that there would be no namespace collision.
I’m not keen on options 2-4 and 5 would indeed make life more complicated. The URL parameter idea is probably the best one as it is “out of band” and all the URLs should be generated by us.
Okay, I have a work in progress branch that I would love your feedback on, if you have time. I’ve added the ability to:
Serve static files with the ?rclone=static URL param
Implemented a slightly richer GUI:
The ability to navigate “up” a directory
Show file sizes and modification times
This is important because, when we want to add even more features (yay!) to the GUI, we won’t be limited to the fields which are currently in the serve.DirEntry data structure.
May I suggest adding a job Id to each of the file being transfered? And setting the job passed on the command line as jobid=0 or 1 (in case the command is no rcd)?
This would make the creation of a API based GUI much simpler and consistent.
Also, is there a way to get info like: total size of the job (in bytes), number of files to be transfered, etc. To display progress information much like -P does?
I’ve written (and updated) a quick and dirty JavaScript (around 300 lines now) that display a sync job running on one of my NAS boxes. It’s a framework, with room for a lot of improvement (specially in formatting), but does the job nicely, specially for long jobs (like initializing a large backup).
Bellow is a snapshot of the simple screen. I do not intend to make a complete GUI to configure rclone or setup/start jobs, but good enough to allow monitoring multiple jobs running on different hosts, with some graphic progress information and allow changing some parameters on the fly (other than bandwidth) for performance tuning (if it works). All files are statick HTML/CSS/JS and can be serverd by rclone, so no backend required.
I wouldn’t mind using something like this from a browser behind caddy on my remote vps. It would be nice to have something to monitor jobs that way. And drill to the log (potentially increase verbosity of it on the fly with RC).
Hello! I have not made too much progress on this, for two reasons:
I’m getting married, and wedding planning has been taking all of my time!
I’ve been learning vue.js, and contemplating a different implementation, whereby the GUI is purely javascript based, and then we make ajax calls to the existing JSON endpoints which rclone has. This may simplify the work so that the development is purely frontend changes, rather than also changing some of the underlying models and datastructures.
My apologies for the delay here! No ETA on my end, but thought I’d drop in and let you know what is happening with me!