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
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. It would be good to have something in between the hook special remote and
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: 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 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 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 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 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]] --[[Joey]]