Scripting Config

[Luminarys]

As noted in #150 it seems like some form of event based scripting system would be useful to have and close out some feature requests.

Current thought is to have a config section like

[[scripting]]
# RPC criteria
criteria = { field = "torrent.progress", op = "==", value = "1.0" }
# List of fields to pass to the script in argv
fields = [
  "name",
  "size"
]
command = ["echo", "$SY_ARG_0", "$SY_ARG_1"]

We'll probably want to in some way expose all resource types so that events on torrents allow access to file/tracker/peer resources, maybe via special variables.

[evanrichter]

as discussed in #150, there are potential security implications when executing scripts or commands with externally provided arguments or input.

It's my hope that the synapse client would be a secure service with any given user configuration, and certainly the configuration shouldn't be regarded as secret information (see the rise in popularity of sharing dotfiles publicly). The RPC interface is the boundary of that responsibility-- what users do with that is up to them.

That said, I do think an event/response system could be useful for automation tasks like moving files while continuing to seed. Would others like to comment with actions they are hoping for, besides arbitrary script execution? I think implementing discrete actions (yes, even if calling execve anyway) would be better than arbitrary scripting. That way, the proper argument and input sanitization would be available to all synapse users at once, by default.

[colemickens]

Thoughts:

1. I wish "move completed" could be offered an exception and just implemented. It's a highly needed/wanted feature, and in my opinion would help make Synapse an easy choice for a "deploy and forget" stable torrent engine.

2. Scripting is neat... but honestly I immediately closed and nope'd out of rtorrent when I saw what it took to implement this sort of functionality. I'd rather go write the feature for cloud-torrent/simple-torrent than learn some esoteric fragile scripting.

3. What would scripting even look like for this? How does one move the download without breaking seeding?

Maybe the approach is just exposing enough RPC functions that users can write standalone script/jobs?

I could have a script that runs every 10 seconds and does:

• RPC query for finished downloads
• (my code) filter all downloads, ignore ones that are already residing in FINAL_DEST
• for any finished downloads, call RPC "move download folder"

Then, since I'm asking Synapse to move the download dir, it can keep seeding files, etc. But still, I'd rather this were just a config option so that I could send a quick PR and get on with life.

Any thoughts? It's been a year?