response
This commit is contained in:
parent
04f75ccedf
commit
cf85370ade
2 changed files with 14 additions and 1 deletions
|
@ -134,7 +134,7 @@ replying with `UNSUPPORTED-REQUEST` is acceptable.
|
|||
(without downloading it). The remote replies with one of `CHECKURL-FAILURE`,
|
||||
`CHECKURL-CONTENTS`, or `CHECKURL-MULTI`.
|
||||
* `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.
|
||||
This will be displayed to the user by eg, `git annex whereis`. The remote
|
||||
replies with `WHEREIS-SUCCESS` or `WHEREIS-FAILURE`.
|
||||
|
|
|
@ -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.
|
||||
"""]]
|
Loading…
Reference in a new issue