added new transfer control page to webapp

I have a preliminary design that looks pretty good

doc/design/assistant.mdwn

@@ -11,9 +11,9 @@ and use cases to add. Feel free to chip in with comments! --[[Joey]]
 
 We are, approximately, here:
 
-* Month 4 "polishing": [[!traillink cloud]] [[!traillink leftovers]]
+* Month 4 "polishing": [[!traillink cloud]] [[!traillink transfer_control]]
 * Month 5 user-driven features (see [[polls]])
-* Months 6-7 "9k bonus round": [[!traillink Android]] [[!traillink partial_content]]
+* Months 6-7 "9k bonus round": [[!traillink Android]] [[!traillink partial_content]] [[!traillink leftovers]]
 * Months 8-11: more user-driven features and polishing (see remaining TODO items in all pages above)
 * Month 12: "Windows purgatory" [[Windows]]
 
@@ -25,6 +25,7 @@ We are, approximately, here:
 
 * [[desymlink]]
 * [[deltas]]
+* [[!traillink leftovers]]
 
 ## blog
 

doc/design/assistant/cloud.mdwn

@@ -17,21 +17,16 @@ More should be added, such as:
 * [nimbus.io](https://nimbus.io/) Fairly low prices ($0.06/GB);
   REST API; free software
 
-## limited space
+## The cloud notification problem
 
-When syncing via the cloud, space there is probably limited, so
-users with more files than cloud space will want to be able to use the
-cloud as a temporary transfer point, which files are removed from after
-they've propigated out.
+Alice and Bob have repos, and there is a cloud remote they both share.
+Alice adds a file; the assistant transfers it to the cloud remote.
+How does Bob find out about it?
 
-Other users will want to use the cloud as the canonical or backup location
-of their data, and would want a copy of all their files to be kept there.
-That's also ok.
-
-git-annex will need a way to tell the difference between these, either
-heuristically, or via configuration.
-
-Also needed for USB keys and Android gadgets.
+There are two parts to this problem. Bob needs to find out that there's
+been a change to Alice's git repo. Then he needs to pull from Alice's git repo,
+or some other repo in the cloud she pushed to. Once both steps are done,
+the assistant will transfer the file from the cloud to Bob.
 
 ## storing git repos in the cloud
 

doc/design/assistant/transfer_control.mdwn

@@ -0,0 +1,66 @@
+Some remotes are too small to sync everything to them.
+
+The case of a small remote on a gadget that the user interacts with,
+such as a phone, where they may want to request it get content
+it doesn't currently have, is covered by the [[partial_content]] page.
+
+But often the remote is just a removable drive or a cloud remote,
+that has a limited size. This page is about making the assistant do
+something smart with such remotes.
+
+## specifying what data belongs on a remote
+
+Imagine a per-remote `annex-accept` setting, that matches things that
+should be stored on the remote.
+
+For example, a MP3 player might use:
+`smallerthan(10mb) and filename(*.mp3) and (not filename(junk/*))`
+
+Adding that as a filter to files sent to a remote should be
+straightforward.
+
+A USB drive that is carried between three laptops and used to sync data
+between them might use: `not (in=laptop1 and in=laptop2 and in=laptop3)`
+
+In this case, transferring data from the usb repo should
+check if `annex-accept` then rejects the data, and if so, drop it
+from the repo. So once all three laptops have the data, it is
+pruned from the transfer drive.
+
+It may make sense to have annex-accept info also be stored in the git-annex
+branch, for settings that should apply to a repo globally. Does it make
+sense to have local configuration too?
+
+## repo classes
+
+Seems like git-annex needs a way to know the classes of repos. Some
+classes:
+
+* enduser: The user interacts with this repo directly.
+* archival: This repo accumulates stuff, and once it's in enough archives,
+  it tends to get removed from other places.
+* transfer: This repo is used to transfer data between enduser repos,
+  it does not hold data for long periods of time, and tends to have a
+  limited size.
+
+Add a class.log that can assign repos to these or other classes.
+(Should a repo be allowed to be in multiple classes?)
+
+Some examples of using classes:
+
+* Want to remove content from a repo, if it's not an archival repo,
+  and the content has reached at least one archival repo:
+
+  `(not class=archival) and (not copies=archival:1)`
+
+  That would make send to configure on all repos, or even set
+  a global `annex.accept` to it.
+
+* Make a cloud repo only hold data until all known clients have a copy:
+
+  `not inall(enduser)`
+
+## configuration
+
+The above is all well and good for those who enjoy boolean algebra, but
+how to configure these sorts of expressions in the webapp?

doc/design/assistant/webapp.mdwn

@@ -25,12 +25,6 @@ The webapp is a web server that displays a shiny interface.
   over http by the web app
 * Display the `inotify max_user_watches` exceeded message. **done**
 * Display something sane when kqueue runs out of file descriptors.
-* possibly add a desktop file to the top of the repository that can be used
-  to open the webapp (rather than using the menus). Would be complicated
-  some by the path to git-annex sometimes needing to be hardcoded and varying
-  across systems, so it would need to be a symlink to `.git/annex/desktop`
-  which would be per-system.
-* add menu item on OSX?
 
 ## first start **done**