FISH: drop compatibility with FISH protocol

[andrew_b]

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.

[andrew_b]

Branch: 4232_drop_fish_protocol
changeset:f42d67432bf76b6e8e2b2d9b5cb70b4f62b549a3

[zaytsev]

I have no problem dropping FISH server "compatibility" since there is no known FISH server to the humankind. I think this was the idea of Pavel, but it never happened this way. Instead other people got inspired by the protocol (I know it's used in KDE), but it was always implemented on the client side. Basically, expect that ssh server provides some kind of POSIXy environment, however crippled, and send POSIX snippets that are run in the shell to execute commands. Something like Ansible does with Python.

Maybe it's worth noting that far2l people are actively working on implementing FISH, but they can't take code from us, because they are GPL 2 and we are GPL 3+: ​https://github.com/elfmz/far2l/issues/1819 - their idea seems to be to write a FISH server in POSIXy stuff and talk to that, instead of sending shell scripts every command. Maybe we can take code from them if we want, and it doesn't make sense to actively break FISH protocol compatibility unless we really need it for some commands :)

I think our commands are good enough after the last rewrite in that they kind of work, what is not so great is the implementation - I would have documented the userlands that they target and wrapped them into functions so that the structure is clear and everything can be modified in a much easier way. The test situation I think is also not so great...

[zaytsev]

By the way, why do we still have the hardcoded scripts in the header file in the first place? I thought actually everything is working via scripts in files. Maybe the hardcoded scripts should be removed...

[andrew_b]

Replying to zaytsev:

By the way, why do we still have the hardcoded scripts in the header file in the first place?

Key bindings too.

I thought actually everything is working via scripts in files. Maybe the hardcoded scripts should be removed...

As I remember, the idea was have more or less working mc with minimum number of external files.

[andrew_b]

The next (obvious?) step is to rename fish to shell, because modified VFS is no longer related to the FISH protocol.