Design a convenient way to deal with progress (workDone and partial results)

[mickaelistria]

I'd like to implement support for partialResults against completion in LSP4E. As far as I understood, it requires me to generate a token, pass it to the request, send the request and then monitor both request future and start monitoring all $/progress notifications for those that have the same token. While it can be made to work, I'm not sure it's the most convenient approach. Here are some blurry ideas to improve it in a way that would fit better LSP4E:

1. make that the partialResult token is automatically bound to the future, so that requestFuture.getNow() would return the the current partialResult, without clients to both with it.
2. Provide some variants APIs so that for responses that are sequences, a Queue is returned so on can plug a reactive consumer on those.

I think working on proposal 1. can already provide some value. If there is some consensus that it is a good idea to provide it, I may try to provide a patch after my holiday. @jonahgraham @pisv @jcompagner @rgrunber WDYT?

[pisv]

It does not look like a good idea to try to use CompletableFuture.getNow for obtaining the current partial result, as it would really break the method contract: it is intended to provide the result value of a completed computation, and cannot be used for providing a sequence of partial results of a computation in progress.

Regarding the second part of your proposal regarding the API variants, I cannot see a good way to provide such API variants in general. For one thing, the same LSP4J APIs are used by both client-side and server-side implementations. For another thing, progress support is optional in LSP.

Therefore, I think that this proposal would better fit a client-side framework based on LSP4J rather than LSP4J itself. For example, LXTK already implements general progress support for the client-side.