I would like to understand the role of the Flush request in the ABCI client/server protocol. I'm filing this issue to solicit input from others who may know more about the history of this implementation, beyond what is in the git blame.

Background

The ABCI client and server interfaces each declare a Flush operation (client, server). This is not part of the application protocol.

Discussion

Given that:

• The local client implements this as a no-op (there is no server in this configuration).
• The socket client implements it by sending the request to the server, with the side-effect of flushing the buffered writer it holds on the socket.
• The gRPC client either does nothing (FlushSync) or sends the request to the server (FlushAsync), with no side effects.
• The gRPC server implements flush by sending an empty confirmation response.
• The socket server implements flush by sending the same empty response, with the side-effect of flushing the buffered writer it holds on the socket.

It appears to me that this method is not actually relevant to ABCI at all, but rather a hack to support the way the socket protocol is implemented. Is that correct, or does this method have some other intended role in the ABCI client-server communication?

Relatedly: If we were to remove this method from the interface in the future, would servers in other languages be affected? If so, are there any examples of what servers are doing with the request as it is currently set up?