summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2012-09-13 17:31:43 -0400
committerGravatar Joey Hess <joey@kitenet.net>2012-09-13 17:31:43 -0400
commitecb9d52770fe123a60183697e595fd42c6e80ba1 (patch)
tree5990c1889047460b842dc3710e562c2ac485041f
parent811f81f48146ae8f629509edcf43596e0be5a070 (diff)
blog for the day
-rw-r--r--doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn34
1 files changed, 34 insertions, 0 deletions
diff --git a/doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn b/doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn
new file mode 100644
index 000000000..45a7e9f20
--- /dev/null
+++ b/doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn
@@ -0,0 +1,34 @@
+It's possible for one git annex repository to configure a special remote
+that it makes sense for other repositories to also be able to use. Today I
+added the UI to support that; in the list of repositories, such
+repositories have a "enable" link.
+
+To enable pre-existing rsync special remotes, the webapp has to do the same
+probing and ssh key setup that it does when initially creating them.
+Rsync.net is also handled as a special case in that code. There was one
+ugly part to this.. When a rsync remote is configured in the webapp,
+it uses a mangled hostname like "git-annex-example.com-user", to
+make ssh use the key it sets up. That gets stored in the `remote.log`, and so
+the enabling code has to unmangle it to get back to the real hostname.
+
+---
+
+Based on the still-running [[prioritizing_special_remotes]] poll, a lot
+of people want special remote support for their phone or mp3 player.
+(As opposed to running git-annex on an Android phone, which comes later..)
+It'd be easy enough to make the webapp set up a directory special remote
+on such a device, but that makes consuming some types of content on the
+phone difficult (mp3 players seem to handle them ok based on what people tell
+me). I need to think more about some of the ideas mentioned in [[android]]
+for more suitable ways of storing files.
+
+One thing's for sure: You won't want the assistant to sync all your files
+to your phone! So I also need to start coming up with partial syncing
+controls. One idea is for each remote to have a configurable matcher for files
+it likes to receive. That could be only mp3 files, or all files inside a
+given subdirectory, or all files *not* in a given subdirectory. That means
+that when the assistant detects a file has been moved, it'll need to add
+(or remove) a queued transfer. Lots of other things could be matched on,
+like file size, number of copies, etc. Oh look, I have a
+[beautiful library I wrote earlier](http://joeyh.name/blog/entry/happy_haskell_hacker)
+that I can reuse!