It is safe to say that the language server protocol (LSP) is the future of developer tools. When it comes to the equivalent for debug, the debug protocol is ‘LSP for debuggers’. It is a useful tagline but here are three key differences to be aware of:
- State – the big mindshift with LSP is that servers are stateless. The clients store all the state e.g. the files themselves and settings (what language, classpath, etc). Any state kept on the serverside (e.g. the index) is usually purely for performance reasons. What this means is that, for instance, servers can be restarted and carry on seamlessly without having to know anything of what happened in the system beforehand. On the other hand, the debug protocol is not stateless, servers need to know all sorts of state and sequences of what has happened, so the design space is different for this protocol.
- JSON RPC 2.0 Spec (and cancellable requests) – The LSP defines JSON-RPC messages for requests, responses and notifications. The debug protocol was created before JSON RPC 2.0 spec was finalized, debug protocol uses a similar structure, but it is not cross compatible. For example, the JSON field name for the method to call is command in debug protocol and method in JSON RPC 2.0. The type of message (event, request, or response) is explicit in DSP in the type field, but is implicit in JSON RPC 2.0 (based on presence of the combination of method, id, result and error fields). However using a library like org.eclipse.lsp4j.jsonrpc can hide such differences and provide equivalent higher level abstractions (like Java interfaces) and leave the library to handle the differences. The LSP has a nice feature, cancellable requests, that is an extension to JSON RPC2.0 that is also not available in the debug protocol: https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#-cancellation-support
- Ubiquity – although the LSP was defined originally for use in VS Code do you know that the 2 flagship languages for VS Code are not based on LSP? Typescript and javascript language tooling is not done using LSP. On the other hand the debug protocol does underpin all the debugger implementations in VS Code, including the flagship node debuggers for V8 and Chrome.
All that being said, it’s worth repeating the common benefits of both protocols which are:
- good separation of client/server
- building the tooling once and reusing it across IDEs and editors i.e. vs code, eclipse, atom, etc
- better unit/isolated testing
- write in language most suited to the job
- more effective way for tool developers to keep pace with underlying tools
Kichwa Coders 