This commit is contained in:
parent
a0cef0d359
commit
ad39eb235a
1 changed files with 13 additions and 0 deletions
13
doc/todo/support_for_writing_external_special_remotes.mdwn
Normal file
13
doc/todo/support_for_writing_external_special_remotes.mdwn
Normal file
|
@ -0,0 +1,13 @@
|
|||
It would be good to have something in between the hook special remote and the built-in special remotes.
|
||||
The hook is easy to set up, but its simple interface misses some features that a more full-features interface could provide to a third-party program that wants to provide the best possible special remote it can w/o being written in haskell:
|
||||
|
||||
* No way to send progress updates when uploading, so no progress bars for uploads from hook special remotes in the webapp.
|
||||
* No way to verify the `initremote` parameters include all needed configuration, and do any initalization needed.
|
||||
* No way to query and/or set the remote.log while it's running. (Well, technically, `git annex enableremote` can set values..)
|
||||
* No way to store per-key information to the git-annex branch.
|
||||
|
||||
These features could be added to git-annex as subcommands. Which would improve the general programmability and flexability of git-annex. OTOH, running `git-annex upload-progress` repeatedly is pretty ugly. Or the interface could provide a channel for the program and git-annex to communicate back and forth on. Maybe a mix of the two?
|
||||
|
||||
A final feature such an interface should provide is the ability to drop a program into PATH and have it just work, without the user needing to do any configuration beyond `initremote`. So, `git annex initremote foo type=$bar` should look for `git-annex-remote-$bar` in PATH if that's not a built-in special remote name.
|
||||
|
||||
--[[Joey]]
|
Loading…
Add table
Reference in a new issue