The Language Server Protocol — LSP is a Json-RPC API being used between a tool (the client) and a language smartness provider (the server) integrate features like auto complete, goto definition, find all references and alike into the tool. It has orignally been created and developed by Microsoft for Visual Studio Code. It has recently gain a lot of popularity among editors/IDE and programming language developers as one can see from the following lists:
- Protocol implementations
- Tools supporting the Language Server protocol
- Language Server Protocol SDKs (to implement language servers in different programming languages)
The website langserver.org also aims at listing existing protocol implementations with some details about the supported features (not all implementations implement (sic.) the complete protocol).
However, LSP is not a silver bullet. First some very important features for advanced editing are not provided by LSP: syntax higlighting, code folding, bracket matching... These are all delegated to the actual editor. Also, language servers are hard to install. Being written in various languages for various platforms, their dependencies are hard to track. They may conflict with the environment one would like to install the server onto. Current workaround is to rely on LSP implementers to provide ready to use "packages" for each LSP-aware tools. Unfortunately, it defies the purpose of LSP.
Therefore, the goal is to push the idea of LSP and define an ubiquitous metadata registry about language support for any editors/IDEs.
Eclipse LSPHub is a metadata registry of language support tooling. It consists of a REST API along with a reference implementation.
It also provides an exemplary client implementation for the Eclipse IDE and possibly other editors/IDE.
It is out of scope to actually store binaries of language servers implementations or related language support artifacts.
Eclipse LSPHub defines a data model for a kind of ubiquitous plug-ins format for all editors/IDEs. It focuses on describing artifacts that implements platform/tools indenpendent language services like LSP.
The data model defines the concept of an Extension which is a logical group of Contributions. A contribution provides support for editing file of given types (typing is being made via UTI).
A TextMate grammar is an contribution. It provides syntax higlighting support for language. LSPHub stores the required metadata for a TextMate grammar to be used: the URI to the actual grammar file(s) and the "scopeName".
A language server is another contribution. It provides the features described by the LSP. However, as there is no uniform packaging format for language servers, LSPHub can not store metadata about it. LSPHub thus define a packaging format for language server in the form of a Docker image. A language server would then be built as a Docker image along with all its dependencies and LSPHub will store the Docker image information (imageName, repository where to find it, version, exposed ports, etc.) along with additional metadata about the language server itself: the RPC configuration (whether it uses pipes, TCP sockets, etc.), the command to start the language server inside the container... This provides an homogeneous format that could be reused by any editor/IDEs to start a language server.
The combination of a language server and a TextMate grammar contributions will make a Extension that will offer an advanced language support to a tool.
LSPHub defines a REST API on top of this data model. Responses are in Json or XML format. Currently, it is only a prototype where extensions can be queried by the type of files they have contributions for, e.g.:
curl -i -X GET --header 'Accept: application/json' http://lsphub.eclipse.org/extensions?uti=public.php-script
will reply
HTTP/1.1 200 OK
Date: Tue, 11 Jul 2017 18:02:01 GMT
Content-Length: 1188
Server: Jetty(9.4.1.v20170120)
)]}'
[
{
"type": "http://www.eclipselabs.org/lsphub/model#Extension",
"symbolicName": "org.eclipselabs.lsphub.phplang.support",
"displayName": "PHP Support",
"version": "1.0.0",
"contributions": [
{
"type": "http://www.eclipselabs.org/lsphub/model#LanguageServerDockerImage",
"symbolicName": "felixfbecker.php-language-server",
"displayName": "PHP language server",
"utis": [
"public.php-script"
],
"imageName": "mbarbero/phpls",
"tag": "latest",
"command": [
"php",
"vendor/felixfbecker/language-server/bin/php-language-server.php"
],
"rpcConfigurations": [
{
"type": "http://www.eclipselabs.org/lsphub/model#PipeConfiguration"
}
]
},
{
"type": "http://www.eclipselabs.org/lsphub/model#TextMateGrammar",
"symbolicName": "org.eclipselabs.php-tm-grammar",
"displayName": "PHP TM Grammar",
"utis": [
"public.php-script"
],
"grammarUris": [
"http://uri.of.the.grammar"
],
"scopeName": "source.php"
}
]
}
]
I do not expect any legal issue.
- Add support for publishing extensions (POST API)
- Replace the in-memory model with a CDO/DB backed model
- Add support for Debug Server Protocol in extensions
Initial contribution can be done as soon as the project proposal is accepted. First build will be ready beginning of the year 2018. A running prototype will be made available at https://lsphub.eclipse.org
- Max Andersen (Red Hat)
- Mickael Istria (Red Hat)
- Gorkem Ercan (RedHat)
- Jonah Graham (Kichwa Coders)
- Tracy Miranda (Kichwa Coders)
- John Duimovich (IBM)
The code is available at Github (https://github.com/mbarbero/lsphub). It currently implements a prototype of the REST API in the form of a webapp. It is written in Java 8 with JAX-RS. It uses OSGi as its runtime and uses a couple of specifications, including some to-be-released OSGi R7 specifications, e.g., the JAX-RS Whiteboard specification.
First level dependencies are:
- Eclipse EMF,
- Google Guava,
- (compile-time only) Google Auto-value,
- Google Gson
- (runtime only) Apache Felix for OSGi runtime and core specification implementations,
- (runtime only) Apache Aries for OSGi JAX-RS Whiteboard specification implementation.
The current webapp is build with Maven+bnd and creates an uberjar that can be deployed on any Java 8 supported environment.
The registry uses and implements the idea of Uniform Type Identifier — UTI to type the metadata and to check whether they apply, or not, to artifacts from the editors/IDEs.
The initial contribution also include an Eclipse plug-in and feature that provides a prototype of a LSPHub client. It tests that the various extension contributions can be registered dynamically to the Eclipse extensions registry.
- Log in to post comments