| I like remote_copy as a flexible interface. Underneath, the Transport API would still need to operate with upload/download semantics as not all transports can inter-operate. If you're transferring between things that support scp-semantics (like SSH and SSH) we could have an override implementation for remote_copy. To support a remote_copy on the CLI, we would want to have something similar to scp's syntax for declaring local and remote files. URIs already have a path component that we're not using, which would make sense here. So you would have commands like
bolt file copy local_file.txt ssh://user:password@pluto:22/tmp/local_file.txt
|
There are some quirks to the above that seem sensible:
- an unadorned file is a "local" file, implicitly mapping to a URI like local:///local_file.txt
- I chose file copy because that better fits our model of object action. That suggests we should use file_copy for the function rather than remote_copy.
- it should otherwise follow the semantics Henrik outlined: Array[Target] -> Target, Target -> Array[Target], Target -> Target are all supported but not array to array.
A with_path helper on Target would be nice so you can pass $target.with_path('/tmp/foo.txt'), or
get_targets($nodes).map |$t| { $t.with_path('/tmp/foo.txt') } |
I think adding directories as a source in BOLT-191 would fit onto this cleanly (copy the directory recursively instead of a single file, require that the destination not exist). |
