update proposed external special remote protocol

This commit is contained in:
Joey Hess 2017-08-28 15:34:26 -04:00
parent 792e582a60
commit ed5d8ee9ea
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 43 additions and 11 deletions

View file

@ -108,28 +108,36 @@ would be overkill if it's only used to support resuming partial uploads.
This needs some additional methods added to special remotes, and to This needs some additional methods added to special remotes, and to
the [[external_special_remote_protocol]]. the [[external_special_remote_protocol]].
* `TRANSFEREXPORT STORE|RETRIEVE Key File Name` Here's the changes to the latter:
Requests the transfer of a File on local disk to or from a given
Name on the special remote. * `EXPORT Name`
The Name will be in the form of a relative path, and may contain Comes immediately before each of the following requests,
path separators, whitespace, and other special characters. specifying the name of the exported file. It will be in the form
of a relative path, and may contain path separators, whitespace,
and other special characters.
* `TRANSFEREXPORT STORE|RETRIEVE Key File`
Requests the transfer of a File on local disk to or from the previously
provided Name on the special remote.
The Key is provided in case the special remote wants to use eg The Key is provided in case the special remote wants to use eg
`SETURIPRESENT`. `SETURIPRESENT`.
The remote responds with either `TRANSFER-SUCCESS` or The remote responds with either `TRANSFER-SUCCESS` or
`TRANSFER-FAILURE`, and a remote where exports do not make sense `TRANSFER-FAILURE`, and a remote where exports do not make sense
may always fail. may always fail.
* `CHECKPRESENTEXPORT Key Name` * `CHECKPRESENTEXPORT Key`
Requests the remote to check if a Name is present in it. Requests the remote to check if the previously provided Name is present
in it.
The remote responds with `CHECKPRESENT-SUCCESS`, `CHECKPRESENT-FAILURE`, The remote responds with `CHECKPRESENT-SUCCESS`, `CHECKPRESENT-FAILURE`,
or `CHECKPRESENT-UNKNOWN`. or `CHECKPRESENT-UNKNOWN`.
* `REMOVEEXPORT Key Name` * `REMOVEEXPORT Key`
Requests the remote to remove content stored by `TRANSFEREXPORT`. Requests the remote to remove content stored by `TRANSFEREXPORT`
with the previously provided Name.
The Key is provided in case the remote wants to use eg The Key is provided in case the remote wants to use eg
`SETURIMISSING`. `SETURIMISSING`.
The remote responds with either `REMOVE-SUCCESS` or The remote responds with either `REMOVE-SUCCESS` or
`REMOVE-FAILURE`. `REMOVE-FAILURE`.
* `RENAMEEXPORT Key OldName NewName` * `RENAMEEXPORT Key NewName`
Requests the remote rename a file stored on it from OldName to NewName. Requests the remote rename a file stored on it from the previously
provided Name to the NewName.
The Key is provided in case the remote wants to use eg The Key is provided in case the remote wants to use eg
`SETURIMISSING` and `SETURIPRESENT`. `SETURIMISSING` and `SETURIPRESENT`.
The remote responds with `RENAMEEXPORT-SUCCESS`, The remote responds with `RENAMEEXPORT-SUCCESS`,

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="joey"
subject="""comment 15"""
date="2017-08-28T19:00:10Z"
content="""
Since [[bugs/external_special_remote_protocol_broken_by_key_with_spaces]]
was fixed, the Key can't contain spaces any longer.
The File could still contain spaces, eg when exporting from a direct mode
repository where the worktree filename contains spaces.
In `RENAMEEXPORT`, both OldName and NewName could contain spaces.
"""]]

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 16"""
date="2017-08-28T19:32:06Z"
content="""
I've updated the proposed external special remote protocol to avoid the
whitespace concerns. Not wild about needing a separate EXPORT request,
which will probably get shoved into a global variable in most
implementations. But it does avoid needing to use some kind of encoding,
which would complicate implementations more, I feel.
"""]]