Prototype for a nicer built-in web GUI

#13

I will say, it might be worth while to add the new web GUI as rclone serve http_new or something. The one that is there right now is slim for quick and dirty with minimal resource requirements – on both the front and back end.

#14

It is possible to build web GUIs using the https://rclone.org/rc/ - check out https://rclone.org/commands/rclone_rcd/ also - you make your GUI then rclone will serve it for you and you can access the API.

I made a proof of concept react app to do this. I’m not a frontend developer so it has been hard work for me!

#15

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:

  1. 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.

  2. 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.)

  3. Choose not to use any HTML features which rely on static assets, such as images. This could be very limiting.

  4. 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.

  5. 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.

Cheers!

#16

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.

#17

I like the URL parameter idea (?rclone=static) - didn’t even think of doing something like that. Will take that direction. Thanks!

#18

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.

Here is a preview:

rclone_directory

And here is my branch thus far: https://github.com/ncw/rclone/pull/2874

Does this seem like it’s going in a direction that make sense?

#19

Great :slight_smile: I added some comments on the pull request.

#20

This seems rather interesting - how’s the progress?

#21

I’ve been trying to use rc and rcd to create an interface to monitor jobs running on a NAS box.

What I haven’t found yet is a way to obtain -P(rogress) like information. Any ideas how to do it?
something like job/progress ???

Tks!

#22

You can use core/stats which should have most things in!

#23

I really missed it. Thanks. I was looking for something related to job/xxxx.

How does it work when more than one job is running (if I understand correctly you could run more than on job, right?).

Tks again!

#24

You’ll get combined stats for all the jobs I think. I’ve not tried it actually!

#25

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?

Many thanks once again.

#26

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.

If anyone is interested, I can upload to github.

59%20PM
Screen Shot 2019-04-11 at 8.14.59 PM.png625×604 55.1 KB

2 Likes
#27

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).

#28

That looks very interesting - I would like to see it please :smile:

#29

Will finish some changes (to make it simpler to configure) and will upload to github.

1 Like
#30
1 Like
#31

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!

#32

Congratulations!
See you soon for news about your web-based GUI.