eclipse-glsp
Consider ways to simplify creation of new Client/Server Actions/Commands
Adding new Client/Server Actions/Commands/Handlers is a relatively common feature, almost always following the same pattern:
- An Action is defined (Twice, Client + Server)
- A Handler is implemented on the Server
- The server replies with a different Action (Implemented twice, Action + Client)
- The Client implements a Command for the reply
If this action requires diagram feedback, we can add another Action + Command on the client side.
In total, for a single feature, we need to implement 2 or 3 Actions, both on the Client and Server, as well as 1 Handler, 1 Command, and maybe one FeedbackCommand (For a total of up to 8 Classes for a single client-server round-trip, most of which doing nothing: only the Command and Handler actually contain some logic).
One example is the "RequestMarkers" action, which needs the following classes:
- RequestMarkersAction (Client, Server)
- RequestMarkersHandler (Server)
- SetMarkersAction (Client, Server)
- SetMarkersCommand (Client)
- ApplyMarkersAction (Client, feedback)
- ApplyMarkersCommand (Client, feedback)
- (Not directly related, as I'm not sure we always need a new one): ValidationFeedbackEmitter (Client, feedback)
Similar set of actions that require the server to provide some info for displaying feedback would require the same amount of classes. Some actions that don't require client-server feedback still require 6 Classes. Moreover, all these classes reference each other, making it error-prone during refactoring (Even though IDEs help, you still have to at least maintain client/server consistency manually)
Moreover, creating these classes is not sufficient: commands/handlers still need to be declared in several places (DI Module for the client commands, DI Module for the server handler and for the Action(s) handled by the client).
The goal of this issue is to discuss some potential ways to improve this, making new Actions implementation less verbose or easier. It could be about reducing the number of classes required, or adding some tooling to automate their creation.
It would be great if @CamilleLetavernier could come up with some concrete suggestions for improving this API and then we can rediscuss this and who should be doing this work. Thanks! I'm a bit against a solution that requires tooling (like a generator). At least such a tooling based solution should be orthogonal.
@CamilleLetavernier What is the status of this one? Are there concrete suggestions on how we could improve the API? If so we should trigger a new discussion. Otherwise I would close this.
