search

TypeFox / ls-api

MOVED TO
https://github.com/eclipse/lsp4j
20 stars 8 forks source link

Break down io.typefox.lsapi.services module #36

Closed akosyakov closed 7 years ago

akosyakov commented 8 years ago

I would like to break down io.typefox.lsapi.services on the following modules:

module responsibility languages depends on
io.typefox.lsapi.services java interfaces for services defined by the language server protocol java io.typefox.lsapi
io.typefox.lsapi.transport base interfaces to organize communication between the client (tool) and server sides like LanguageEndpoint, MessageReader, MessageWriter, MessageTracer and base or typical implementations of them, like AbstractLanguageEndpoint, ConcurrentMessageReader and PrintMessageTracer java, xtend io.typefox.lsapi
io.typefox.lsapi.json JSON based implementation of MessageReader and MessageWriter java, xtend io.typefox.lsapi.transport
io.typefox.lsapi.client the client (tool) side implementation of LanguageEndpoint for communication with the server side java, xtend io.typefox.lsapi.transport
io.typefox.lsapi.server the server side implementation of LanguageEndpoint for communication with the client (tool) side java, xtend io.typefox.lsapi.transport

Such structure let users only consume what they need, for example:

akosyakov commented 7 years ago

For comparison a decomposition of typescript SDK: https://github.com/Microsoft/vscode-languageserver-node#vscode-language-server---node. It consist of a base package hiding implementation details of the base jsonrpc protocol, and client and server wrappers packaged correspondingly.

Notice how all connection interfaces expose generic method for registering handlers and sending requests and notification, so one can easily extend the protocol.

spoenemann commented 7 years ago

What do you mean by modules? Packages or Jars?

akosyakov commented 7 years ago

@spoenemann jars

spoenemann commented 7 years ago

I don't see the benefit in such a fine-grained splitting into multiple jars. I would understand separating the JSON dependent part in order to get rid of the Gson dependency in cases where you want to implement you own message passing, but otherwise it shouldn't matter to have a few kilobytes more code than you actually need?

akosyakov commented 7 years ago

@spoenemann I don't care about a size either, but rather about clear structure and API. if one implement a server he should not bother with client side interfaces and classes, the same for the client side.

spoenemann commented 7 years ago

Ok, we should discuss this when we review the API after the code transfer to Eclipse.

akosyakov commented 7 years ago

https://github.com/Microsoft/language-server-protocol/issues/86#issuecomment-252194346 - arguments to decouple the LS protocol from the transport level and the transport from json based implementation

akosyakov commented 7 years ago

Also think we should have io.typefox.lsapi.shared that have common useful service on the LS protocol level, e.g. FileWatchingLanguageServer can watch file changes and be applied on the client and server sides.

svenefftinge commented 7 years ago

For lsp4j I splitted it up in two separate modules

I think this is a reasonable splitting, I don't see how anyone would want to use jsonrpc without json, but even that would be possible now. It is just that the json specific stuff is not in its own module (but package).

For the client / server separation, on jsonrpc level there is no distinction as both are just endpoints. On LSP level it makes sense to have the interfaces in one module, as a language server usually gets parameterized with a language client to communicate back (and vice versa).