Reusing language server accross project

[sebthom]

Working on Dart integration with LSP4E I am currently spawning a new LS per Eclipse project.
As I learned today I can also specify a singleton=true attribute in the plugin.xml which tells LSP4E to reuse the same LS across projects.
The problem however is that Dart brings the LS directly as part of its SDK and I want to support the usage of multiple versions of Dart in the same workspace - similar what you can do with JREs in Java Projects.

So I wonder how can I tell LSP4E to reuse the same LS across projects using the same Dart SDK and spawn a new one for projects using another Dart SDK version.

Do we have to extend LSP4E internally, e.g. LanguageServerWrapper.canOperate(project) or is there an existing way to do this.

[rubenporras]

I would not know how to have a mixture between both options.

I guess you would need to extend the existing API to map projects to some property (such as the version you want to use) and then have the singleton extended to be a singleton for each value of the property.

[mickaelistria]

As the language server grows, it faces typical issues of all SDKs (compilers, IDEs...) that has for usual solution to implement backward compatibility so nower SDK can still be used as a tool against older versions. I'm afraid it's the best path forward on mid to long term for your project; but not the easiest or cheapest on short-term...
Basically, your LS becomes a real singleton that spawns children for different targets and takes care of dispatching incoming request from the IDE to the right child LS.

In the meantime, in LSP4E, I don't think there is enough flexibility to implement it. One possible hack would be to define the "dispatching" in your LSP4E StreamConnectionProvider, but overall it wouldn't be really easier than doing it on server-side, although it would not be as reusable.

[ahmedneilhussain]

I was having a think about this as related to my questions about project natures and file-name-based content type associations.

Would it be possible to have a hook where a language server definition could supply a custom implementation of some interface or class as we do for clientImpl and serverInterface? The wrapper/accessor/registry could instantiate this and delegate to it in order to decide whether an existing server/wrapper can bind to a file.

[mickaelistria]

Would the proposal in #400 cover the requirement?

[ahmedneilhussain]

I think it might be nice in the medium term to be able to use project natures in language server definitions directly - it looks like #400 could achieve a lot of what @sebthom wants with a small amount of Eclipse configuration magic, but LSP4e wouldn't be aware of the project natures directly, so it wouldn't help with e.g. the project-symbols issue.