Replies: 2 comments 7 replies
@chrisbra Do you approve of this? Thanks. |
|
Yes very much, thanks for keep pushing improvements here |
|
Hm, I am considering switching to a JSON based protocol, which would be a lot simpler. Only problem is that backwards compatibility is obviously not preserved... |
What do you mean? |
|
I am not sure if this is feasible or even desired, but would it work to use the json protocol only when using the channel backend and otherwise keep the exising one? |
Yes that can be done, but i don't know if having 3 different ways of clientserver would confuse people a lot. Besides, if either tried communicating with each other, it will just result in an error |
|
I guess backwards incompatible is only a concert when you have installed two different versions of Vim, one which would use the old protocol and one would expect the json protocol? But I don't know how common that is, perhaps it won't be much of an issue after all? |
I don't think there are much people using two different versions of Vim and relying on clientserver. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Now that there is
ch_listen()implemented by mattn, the socketserver code can be ported to use channels. When I created the PR that first implemented clientserver as a socketserver, I was not very familiar with network programming. Now that I look at my old code for the socketserver feature, ...things can be much improved. Additionally using channels should fix the GVim issues with clientserver hopefully.Of course everything should be completely backwards compatible with the old socketserver functionality (same protocol used).
This means the channel code will have to be modified to provide a C API as well.
There is also the benefit that the socketserver will no longer be dependent on UNIX domain sockets.
All reactions