Requests vs. Notifications

[KillTheMule]

From the Roadmap:

Consider making a difference between requests and notifications, and send out notifications with the proper message type, and don't wait for a response

Does neovim actually recognize this? Read the docs! Maybe everything's a requests anyways, then don't bother
It does, see https://neovim.io/doc/user/api.html#api-global-events. Maybe not so usefull since there seems little to do where you don't want direct error feedback

So we could send out requests without a real return value, such as nvim_buf_set_lines, as notifications instead.

• Pros:
  • This would save a bit of RPC traffic, as we don't get an answer unless there was an error
• Cons:
  • Need to implement handling the error event
    • Needs design work: Always handle? Let clients handle it on their leisure?
    • Makes everything more complicated
  • Gets us into trouble because of timing issues, we don't know exactly which message the error event belongs to.

My take: It's not worth it.

[KillTheMule]

@fredizzimo I was about to close this, but I saw this affecting neovide, so I'd like to have your input here :)

• What exactly are neovide's specific needs here? Would it help enough to implement just some specific requests as notifications? This would get us a result pretty quickly I guess, but of course it's not really general.
• I'd implement notifications transparently, i.e. they are async functions with no return Value (like https://github.com/KillTheMule/nvim-rs/blob/master/src/neovim_api.rs#L254), it just resolves after writing to the writer instead of waiting on a reply. That way, we'd get writer errors reported directly. Would you envision something else?
• There could still happen an error on neovim's side (like trying to delete a variable here that does not exist). Any idea on error reporting here? I guess we could keep a "request variant' of the function around, so the caller gets to choose if they want to wait for a "success" reply. Or maybe keep something global where we gather errors from notifications?

Thanks for any input :)

[fredizzimo]

Pinging @Kethku and @falcucci and since I'm no longer maintaining Neovide.

But to answer the questions, I think it mostly concerns keyboard and mouse input events. The problem right now is that Neovide doesn't really work over high latency links due to the need to wait for the response for the previous event before the next one can be sent. Imagine for example a keyboard repeat of 30 ms and a latency of 100 ms. In that case the next keyboard event should be sent before the response is received, so things starts to buffer up, and you get a repeat rate of 100 ms, with steadily increasing lag. After 10 presses the lag is already almost 1 second.

So, right now, that would concern the following requests, https://github.com/neovide/neovide/blob/88a7438b7ace290f8339ad276b72cb5723cbb627/src/bridge/ui_commands.rs#L49-L124. But there are actually more coming in neovide/neovide#3221, and perhaps even more in the future. So I think a separate function would be the best. That's probably required anyway due to changed semantics and to not risk breaking existing clients.

To get started it could even be enough to just implement notify, which works like call, but uses rpc notify and doesn't wait for the response. That way the code generation doesn't need to be changed, and it still supports everything. Of course, once the proof of concept is done it could be extended in a more typesafe manner. I think that's close to what you are proposing,if you were planning to send RpcNotification instead of RpcResponse.

Note that I'm assuming that Neovim will actually handle the notify events the same as requests, except that it skips sending the result, but I'm not sure. If that's not case, then some other solution is needed. Neovide could run the requests in parallel without any new support from nvim-rs, but then there's a problem with ordering. It still needs to be guaranteed that Neovim receives the events in the same order as Neovide sends them. So I think that even in that case something needs to be done on the nvim-rs, to guarantee the ordering.

I think all errors and responses should be ignored, since that's the definition of notify. And yes the request variants should stay, so that the user can choose which method to use.