You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
export class RSPClient {
...
/**
* Returns the capabilities implemented by the client
*/
getCapabilities(): Protocol.ClientCapabilitiesRequest {
return {map: {'protocol.version': '0.16.0', 'prompt.string': 'true'}};
}
This version should match the client/protocol version and tends to be forgotten when bumping the client version. We thus should find a way to derive this version from the client version.
A suggestion is to parse package.json, extract the version and use it when building the client. See here: #87 (comment)
The text was updated successfully, but these errors were encountered:
I recognize the problem here, but I'm not sure it's the right solution.
Just because the client jar can support newer APIs doesn't mean the UI is capable of handling them. It is important for the UI to be able to override this and say, yes, even while I am using an rsp-client of 0.16.0, I do not yet truly support 0.16.0. I have not implemented the features that respond to the new APIs and prefer not to receive them. Please use the old APIs.
The reason I feel this is important is as follows:
Imagine we have an API for rsp-server to send a notification to its client. Imagine the first version of this API sends only an error string, or similar. And imagine vscode-adapters implements and properly responds to these events.
Now imagine rsp-server adds a new api: sendMessage(ERROR|WARNING|INFO, msg). rsp-client goes ahead and implements the above. And vscode-adapters consumes this new client.
The rsp-server might say, ok, client 1 says they support 0.16.0 API, so instead of using sendMessage(msg), lets use sendMessage(int, msg) to tell them something happened. vscode-adapter will use the newest client, adn the rsp-client will properly receive the message, but vscode-adapters has not actually plugged in to listen to it. vscode-adapters is waiting for a sendMessage(msg) type message, and never receives one. Instead the message comes in on sendMessage(int, msg) and vscode-adapters has not yet adapted to listen to that brand new API.
I'm not sure if this is convincing, buit it's just an idea ;)
The client reports client capabilities protocol version. See here: https://github.com/redhat-developer/rsp-client/blob/master/src/client.ts#L116
This version should match the client/protocol version and tends to be forgotten when bumping the client version. We thus should find a way to derive this version from the client version.
A suggestion is to parse package.json, extract the version and use it when building the client. See here: #87 (comment)
The text was updated successfully, but these errors were encountered: