diff options
author | 2012-09-23 15:15:01 -0400 | |
---|---|---|
committer | 2012-09-23 15:15:01 -0400 | |
commit | 5adad135907120efec17543b059b17f6bc7b1cdb (patch) | |
tree | 24d2c3c4bf9b4a07be48ec2a0fecfa17e6ede0b4 /doc/design/assistant/transfer_control.mdwn | |
parent | 39e946c4a5775f58c062a6761c5fc6169d145629 (diff) |
added new transfer control page to webapp
I have a preliminary design that looks pretty good
Diffstat (limited to 'doc/design/assistant/transfer_control.mdwn')
-rw-r--r-- | doc/design/assistant/transfer_control.mdwn | 66 |
1 files changed, 66 insertions, 0 deletions
diff --git a/doc/design/assistant/transfer_control.mdwn b/doc/design/assistant/transfer_control.mdwn new file mode 100644 index 000000000..179ec6207 --- /dev/null +++ b/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? |