Merge branch 'master' of ssh://git-annex.branchable.com

2 files changed, 33 insertions, 1 deletions

diff --git a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
index 6b37b68aa..31d189045 100644
--- a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
+++ b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
@@ -6,7 +6,7 @@ locally paired systems, and remote servers with rsync.
 Help me prioritize my work: What special remote would you most like
 to use with the git-annex assistant?
 
-[[!poll open=yes 15 "Amazon S3 (done)" 9 "Amazon Glacier" 7 "Box.com" 55 "My phone (or MP3 player)" 13 "Tahoe-LAFS" 4 "OpenStack SWIFT" 16 "Google Drive"]]
+[[!poll open=yes 15 "Amazon S3 (done)" 9 "Amazon Glacier" 7 "Box.com" 57 "My phone (or MP3 player)" 13 "Tahoe-LAFS" 4 "OpenStack SWIFT" 16 "Google Drive"]]
 
 This poll is ordered with the options I consider easiest to build
 listed first. Mostly because git-annex already supports them and they
diff --git a/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment b/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment
new file mode 100644
index 000000000..2163ba76d
--- /dev/null
+++ b/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="helmut"
+ ip="89.0.176.236"
+ subject="Asynchronous hooks?"
+ date="2012-10-13T09:46:14Z"
+ content="""
+Is there a way to use asynchronous remotes? Interaction with git annex would have to
+split the part of initiating some action from completing it.
+
+I imagine I could `git annex copy` a file to an asynchronous remote and the command
+would almost immediately complete. Later I would learn that the transfer is
+completed, so the hook must be able to record that information in the `git-annex`
+branch. An additional plumbing command seems required here as well as a way to
+indicate that even though the store-hook completed, the file is not transferred.
+
+Similarly `git annex get` would immediately return without actually fetching the
+file. This should already be possible by returning non-zero from the retrieve-hook.
+Later the hook could use plumbing level commands to actually stick the received file
+into the repository.
+
+The remove-hook should need no changes, but the checkpresent-hook would be more like
+a trigger without any actual result. The extension of the plumbing required for the
+extension to the receive-hook could update the location log. A downside here is that
+you never know when a fsck has completed.
+
+My proposal does not include a way to track the completion of actions, but relies on
+the hook to always complete them reliably. It is not clear that this is the best road
+for asynchronous hooks.
+
+One use case for this would be a remote that is only accessible via uucp. Are there
+other use cases? Is the drafted interface useful?
+"""]]