| Re: [che-dev] language server protocol |
|
On 7/7/2016 7:11 PM, Tyler Jewell
wrote:
I would appreciate any further pointers...thanks much.
Yes. Sorry in advance if this is too much: In addition to bundles/modules, OSGi frameworks all have a service registry [1]...a service instance is essentially a pojo that is registered and accessed via by the name of the service interface (java interface class(es) and a set of arbitrary service properties. The OSGi service registry has proven a very useful thing for (e.g.) micro services, service dynamics, injection, service dependencies, service versioning, etc both for Eclipse (many parts of Eclipse are exposed as OSGi services underneath) and for commercial and other servers (Websphere, Karaf, others). Remote Services extends (by spec) OSGi services across processes and 'deals with' many of the associated complications of rpc distribution (e.g. service dynamics, service discovery over network, proxy creation, sync vs. async access, serialization, meta-data standardization, etc). ECF has an impl of Remote Services that supports pluggable distribution providers (i.e. protocols + serialization ...i.e. the underlying rpc). And we have jsonrpc as one of our new distribution providers among quite a few others. Note that for your language servers registry work you might want to look at the discovery part of remote services. What this means/allows is that LSP can/could be easily implemented as a set of OSGi services...and with ECF's jsonrpc provider these services could be accessed as an OSGi service without any direct coding to the LSP protocol and jsonrcp. One use case of all this would be with Eclipse as a client for an LSP language server(s) as OSGi services (there's lots of machinery already in Eclipse to make that easy, dynamic, versionable, etc.). Another would be an Orion server as LSP client...which could likely use much of the same codebase as Eclipse since it's also based upon OSGi. Another would be other web servers that could integrate or aggregate multiple LSP servers with other tools or existing services (e.g. deployment, CI/build) and expose them as their own set of services. Of course also possible is LSP servers implemented as OSGi remote services, making it easier to implement or extend an LSP server or it's services (e.g with custom authentication or authorization). One of the other things we are doing is extending Remote Services to Java-only (no OSGi framework...just Java) and Python runtimes. In any event, the initial use case I thought of was creating micro services for an Eclipse and/or Orion LSP client, but I do think that there's also lots of other use cases around extending LSP servers, aggregating multiple LSPs, integrating with developer services. Scott [1] https://www.osgi.org/developer/architecture/
|