Ticket #4232 (new task)
Opened 2 years ago
FISH: drop compatibility with FISH protocol
| Reported by: | andrew_b | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | Future Releases |
| Component: | mc-vfs | Version: | master |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Branch state: | no branch | Votes for changeset: |
Description
Does anybody know any implementation of FISH server as described in README.fish and Wikipedia? I can't find none of them.
My ask is following: should we keep the compatibility with unimplemented server?
FISH protocol has some limitations, and those limitations don't allow us to resolve #77 and #68.
Let's look at FISH command of getting file from the remote host:
#RETR /path/and/filename <offset>
Using this command, we must get a part of file from offset to the end only. We can't get a chunk of file from offset1 to offset2. And moreover:
Note that there's no way to abort running RETR command - except closing the connection.
The same situation with the commands of sending file to remote host:
#STOR <size> /path/and/filename #APPE <size> /path/and/filename
We cannot send a chunk of file from offset1 to offset2. If we start to send a file with specified <size>, we must transmit all specified <size> bytes.
As a result, we have to use the intermediate storage for transferring files because we must transfer file wholly, not small chunk by small chunk with ability of transfer interruption.
Extending FISH protocol is pointless because who will support those extensions?
Let's forget about the compatibility with FISH command formats. Let's just send shell scripts with arguments that are convenient for us to the remote host and get results of script work. The part of FISH protocol relative to remote host answers will be used as is.
