mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update

Browse source
This commit is contained in:
Joey Hess 2013-05-24 11:59:52 -04:00
parent 56b774d358
commit 84ac6778d9
1 changed files with 16 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
doc/todo/support_for_writing_external_special_remotes.mdwn
View file

@ -1,13 +1,25 @@
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:
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.
* No (easy) way to split files into chunks.
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?
Some of 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.
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]]