CHANGE(server): Remove gRPC implementation #5552
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The gRPC implementation never left the experimental state and never reached a properly stable state to the point where we would feel good about enabling it by default. In addition to that, there has been no further attempts at finding and fixing the encountered issues in the implementation (except mumble-voip#3947 but that was discontinued). As such we had an essentially unmaintained piece of code in our server implementation that was known to be buggy and that nobody wanted to fix. In addition to that the implementation itself could not be considered very clean or elegant and therefore only represented a few smelly corners in our code base. For this reason, we decided to remove the gRPC support entirely from Mumble (for now). What we hope to gain by that is: - Prevent people from building unstable server versions and then coming to us complaining that it crashed/misbehaved - Removing (essentially) dead code - Reduce the RPC implementation complexity That last piece is crucial: By removing gRPC support we reduce the amount of supported RPC frameworks to only one (ignoring DBus for now). Our future plans include a refactoring of how RPC is being handled and implemented and only having to worry about maintaining compatibility with one RPC system is much easier than having to worry about two (with (slightly) different APIs). Once the RPC implementation has been rewritten, more RPC backends may be reintroduced and in that process we might investigate adding a proper gRPC implementation to the code (that then hopefully is more stable than the current one). Fixes mumble-voip#4567 Fixes mumble-voip#4197 Fixes mumble-voip#3496 Fixes mumble-voip#3429 Fixes mumble-voip#3265
This was referenced Mar 27, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The gRPC implementation never left the experimental state and never
reached a properly stable state to the point where we would feel good
about enabling it by default. In addition to that, there has been no
further attempts at finding and fixing the encountered issues in the
implementation (except #3947 but that was discontinued).
As such we had an essentially unmaintained piece of code in our server
implementation that was known to be buggy and that nobody wanted to fix.
In addition to that the implementation itself could not be considered
very clean or elegant and therefore only represented a few smelly
corners in our code base.
For this reason, we decided to remove the gRPC support entirely from
Mumble (for now).
What we hope to gain by that is:
to us complaining that it crashed/misbehaved
That last piece is crucial: By removing gRPC support we reduce the
amount of supported RPC frameworks to only one (ignoring DBus for now).
Our future plans include a refactoring of how RPC is being handled and
implemented and only having to worry about maintaining compatibility
with one RPC system is much easier than having to worry about two (with
(slightly) different APIs).
Once the RPC implementation has been rewritten, more RPC backends may be
reintroduced and in that process we might investigate adding a proper
gRPC implementation to the code (that then hopefully is more stable than
the current one).
Fixes #4567
Fixes #4197
Fixes #3496
Fixes #3429
Fixes #3265
Checks