We already have the workspace/reload request to instruct the server to reload the configuration. Isn't that what you need? What is the difference?

The gap is that, we cannot put the value of the settings as the request body of workspace/reload.

Maybe take a deep look of the Gradle Tooling API can better illustrate the issue: https://docs.gradle.org/current/javadoc/org/gradle/tooling/GradleConnector.html#connect--

From the API, you can find some method like useGradleUserHomeDir()​, useGradleVersion()​, etc...

Imagine that in the IDE, there will be some setting fields to let user specify the Gradle user home dir or Gradle version, then we need a mechanism to let build server know those settings. Meanwhile, when user updates them, a notification needs to be sent to the build server. The notification should contain the new values of those settings - because there is no way to let the build server ask it from client either.

The gap is that, we cannot put the value of the settings as the request body of workspace/reload.

Thanks for the clarification. Would it solve the issue if we add a data field, or settings field, in the params of workspace/reload?

Yes, but might not be the best?

Just my personal understanding of workspace/reload: This notification is used to notify the build server that the configuration files are changed. For example, user edits build.gradle, the build server needs to be notified to reload/resync according to the new build.gradle.

While for the settings, they are different things compare to the configuration files like build.gradle. I'm worrying that things will become not clear if we reuse workspace/reload to handle two different kinds of things.