Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Add support for dynamic capability registration #155

Open
daviwil opened this issue Nov 27, 2017 · 6 comments
Open

Add support for dynamic capability registration #155

daviwil opened this issue Nov 27, 2017 · 6 comments

Comments

@daviwil
Copy link
Contributor

daviwil commented Nov 27, 2017

Language Server Protocol v3 introduces dynamic registration of capabilities, allowing the server to register support of a particular capability with the client, also passing options to configure the client's use of that capability.

This will require us to use a different set of method overloads in vscode-jsonrpc's client library for sending requests and events:

https://github.com/Microsoft/vscode-languageserver-node/blob/master/jsonrpc/src/main.ts#L269

@deankevorkian
Copy link
Contributor

I'm missing something, could you please clarify why we're required to use any of these?
If I understand correctly, according to the spec, the sending is done the same way - we pass a method name, and an args/params object. So in our case, we're just passing an RegistrationParams object which has an array of Registration objects?

@daviwil
Copy link
Contributor Author

daviwil commented Dec 6, 2017

Actually, it seems the RegistrationOptions for the given Request/Notification types aren't even being used in those overloads, they're just a facet of the Request/NotificationType signature. My statement about changing the overloads was incorrect. The largest part of the work will be in dealing with the client/registerCapability request to dynamically wire up language features.

The real reason we would need to change overloads is to make use of the CancellationToken parameter which has nothing to do with dynamic capability registration. Maybe in the future we can make a PR to the vscode-jsonrpc project to add overloads that take a CancellationToken without the need for a Request/NotificationType parameter.

By the way, I love your avatar, that movie is awesome ;)

@deankevorkian
Copy link
Contributor

deankevorkian commented Dec 6, 2017

So, for now we're only going to cancel requests via a $/cancelRequest request until we make a PR to vscode-jsonrpc or if Request/Notification types start receiving a CancellationToken object? I like it.
I understand it's a part of vscode anyway, so why hasn't it been an existing overload on vscode-languageserver-node this whole time? 😕

By the way, I love your avatar, that movie is awesome ;)

;)

@daviwil
Copy link
Contributor Author

daviwil commented Dec 6, 2017

Probably wasn't added as an overload to the "simple" sendRequest/sendNotification methods because vscode-languageclient switched over to the new method of specifying request and notification types before adding request cancellation. I doubt there's a limitation that prevents it from being added, so I'll try to add it and send a PR to them.

@daviwil
Copy link
Contributor Author

daviwil commented Dec 6, 2017

Turns out vscode-jsonrpc does support a CancellationToken parameter in the "overload" of sendRequest which accepts a simple method name and parameter list:

https://github.com/Microsoft/vscode-languageserver-node/blob/master/jsonrpc/src/main.ts#L928

They just look at the last item in the list of params and check if it's a CancellationToken. I'll add this information to issue #140 as well.

@UziTech
Copy link

UziTech commented Oct 19, 2020

Development of atom-languageclient has officially moved to https://github.com/atom-ide-community/atom-languageclient 🎉

If this is still an issue please consider opening an issue on that repo.

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

No branches or pull requests

3 participants