Clarify the motivation: what role do IDEs play?

[keyboardDrummer]

In the motivation it says that the build server can also be used by IDE's:

The Build Server Protocol aims to define common functionality that both build tools (servers) and language servers/editors (clients) understand.

However, as an IDE developer, I want to do as little work as possible per language that I want to support. Given that, and that I'm already connecting to an LSP server, I want the LSP server to provide me with everything I need to know. This includes information such as what test and build targets there are. If there are BSP servers for a language that can answer such questions, I would want the language's LSP server to connect to those BSP servers, and relay any relevant information to the IDE.

For clarity's sake, I will restate my comment in a different way. Given IDE's, language servers, and build tools, if each IDE already knows which language server to use per language, and each language server knows which build tool to use per build format, then why would we also teach the IDE's which build tool to use per build format? That seems like an excess of knowledge that we're putting into the IDE.

Could you confirm in the motivation whether IDE's are supposed to connect to BSP servers or not?

If the answer is yes, then what is the scenario? One option would be that LSP currently is lacking API's that you're already offering with BSP.

[jastice]

There's several reasonable approaches here:

1. build server provides build structure information and commands to language server via bsp. Here the build is transparent to the editor side.
2. bsp is implemented alongside lsp by build tool.
3. bsp as primary protocol between build tool and IDE. This is the use case for IntelliJ, which is essentially its own language server, but it requires mapping the build tool model to the IntelliJ model.

bsp aims to minimize the buildtool-specific implementation work required by an IDE or language server by offering a common protocol and structure that covers most of the ground

[olafurpg]

As I see it. From the client side, BSP abstracts over buildtool-specifics while LSP abstracts over language-specifics. On the server side, BSP abstracts over the IDE-specifics (whether language server or editor) while LSP abstracts over the editor specifics.

As @jastice points out, there are different IDE architectures where BSP might be useful. The motivation section could benefit from concrete examples of how BSP fits into the larger picture.

One option would be that LSP currently is lacking API's that you're already offering with BSP.

There are some methods in BSP that might make sense in LSP like buildTarget/test and buildTarget/run. A language server can already maybe hack those features together via textDocument/codeLens and window/logMessage but a first-class representation might be better.

Given IDE's, language servers, and build tools, if each IDE already knows which language server to use per language, and each language server knows which build tool to use per build format, then why would we also teach the IDE's which build tool to use per build format?

This is a good point. The architecture I have imagined for Metals (a small language server I maintain) was to communicate with build tools without language client (editor) knowing about it.

[jvican]

I want the LSP server to provide me with everything I need to know. This includes information such as what test and build targets there are. If there are BSP servers for a language that can answer such questions, I would want the language's LSP server to connect to those BSP servers, and relay any relevant information to the IDE.

I think editors are interested in connecting to BSP servers on their own because they can use the build tool information to enhance the user experience. For example, by highlighting the base directories of the build targets in a project or showing their project name directly or, more generally, to fetch more projects' metadata that allow the IDEs to provide actions to the user that are not understood/formalized by LSP.

[PavelSosin]

I think that most important scenario is vscode front-end with eclipse/che 7 back-end. Build server is a sidecar of che workspace.NEXT i.e. docker image, regardless how it is implemented. It has direct access to workspace. EDI front-end can be written in any front-end language and communicates with back-end using BSP protocol. Both front-end and back-end implementation are facilitated by official BSP libraries written in corresponding languages.