Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

derive capabilities version from client version #90

Open
adietish opened this issue Jun 6, 2019 · 1 comment
Open

derive capabilities version from client version #90

adietish opened this issue Jun 6, 2019 · 1 comment

Comments

@adietish
Copy link
Contributor

adietish commented Jun 6, 2019

The client reports client capabilities protocol version. See here: https://github.com/redhat-developer/rsp-client/blob/master/src/client.ts#L116

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)

@robstryker
Copy link
Contributor

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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants