Consider having `showMessage` et al be associated with a request id

LSP has a showMessage notification, as well as others that serve a similar purpose, to notify the clients (editors) about what’s happening in the server.

BSP builds upon this infrastructure, but there is a key difference between BSP and LSP in terms of requirements: BSP needs to handle parallel requests, while LSP doesn’t.

This means that when clients (in our case, IDEs, editors and users) want to run tests of different modules in parallel (or similar tasks that require parallel execution) there is no way to know which request trigger certain logs.

We need to figure out what to do to allow clients to separate logs coming from different requests. Should we add another showMessage notification that is associated with a request id?

This question came up when thinking about the Intellij integration with @jastice.

[jastice]

builds and tests may merit special support, but in the case of generic tasks with unspecified semantics, the same considerations can apply.

For instance I could create a deploy task for my project that uploads binaries to several target servers in parallel, and I would like to get a updates on which of these have started, completed successfully, with error, etc.

This is a bit academic since I don’t think most build tools support this kind of structured logging in their APIs, but this lack has been one of my favorite pain points for a long time.

[olafurpg]

To clarify, I think it’s a better idea to introduce custom notification messages to report test/build progress instead of extending showMessage.

Related, there is a related LSP ticket on “Add support to report progress for a running request” https://github.com/Microsoft/language-server-protocol/issues/70 I think it would make sense to draw inspiration from there.