mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

response

Browse source
This commit is contained in:
Joey Hess 2015-09-09 17:09:48 -04:00
parent 04f75ccedf
commit cf85370ade
2 changed files with 14 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/design/external_special_remote_protocol.mdwn
View file

@ -134,7 +134,7 @@ replying with `UNSUPPORTED-REQUEST` is acceptable.
(without downloading it). The remote replies with one of `CHECKURL-FAILURE`, (without downloading it). The remote replies with one of `CHECKURL-FAILURE`,
`CHECKURL-CONTENTS`, or `CHECKURL-MULTI`. `CHECKURL-CONTENTS`, or `CHECKURL-MULTI`.
* `WHEREIS Key` * `WHEREIS Key`
Asks the remote to provide any information it can about ways to access Asks the remote to provide additional information about ways to access
the content of a key stored in it, such as eg, public urls. the content of a key stored in it, such as eg, public urls.
This will be displayed to the user by eg, `git annex whereis`. The remote This will be displayed to the user by eg, `git annex whereis`. The remote
replies with `WHEREIS-SUCCESS` or `WHEREIS-FAILURE`. replies with `WHEREIS-SUCCESS` or `WHEREIS-FAILURE`.

13
doc/design/external_special_remote_protocol/comment_19_89d532a5013af24f15a0d003cbfbab25._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="joey"
subject="""re: WHEREIS -- is it better to just report failure to avoid duplicates?"""
date="2015-09-09T21:03:13Z"
content="""
There's no point in implementing WHEREIS if it's going to reply with the
same values that are passed to SETURIPRESENT.
Some special remotes may not need to use SETURIPRESENT to work at
all, and yet storing data on the remote makes it available from some public
url. This is the kind of situation where it makes sense to implement
WHEREIS.
"""]]