| Age | Commit message (Collapse) | Author |
|---|
|
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:
- 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 #4567
Fixes #4197
Fixes #3496
Fixes #3429
Fixes #3265
|
|
|
|
|
|
This commit introduces a new plugin framework into the codebase of the
Mumble client. Note that "plugin" here really refers to a (more or less)
general purpose plugin and is therefore not to be confused with the
previously available positional data plugins (only responsible for
fetching positional data from a running game and passing that to
Mumble).
The plugin interface is written in C, removing the compiler-dependence
the old "plugins" had. Instead plugins can now be written in an
arbitrary language as long as that language is capable of being compiled
into a shared library and also being capable of being C-compatible.
As already indicated a plugin is essentially a shared library that
provides certain functions that allow Mumble to interface with it.
Inside Mumble the so-called PluginManager is responsible for managing
the plugins and relaying events to the respective callbacks. Plugins
themselves can also interact with Mumble on their own initiative by
using the provided API functions.
Fixes #2455
Fixes #2148
Fixes #1594
Fixes #2051
Fixes #3742
Fixes #4575
Fixes #4751
|
|
This was done by running scripts/updateLicenseHeaders.py and then
manually editing the LICENSE file.
|
|
According to https://www.freebsd.org/releases/ 12.1 is no longer
supported.
This also seemed to cause some problems in the most recent runs of the
Cirrus CI tasks.
Thus this commit updates the used version to 12.2
|
|
In order to make sure we don't break things, we should include gRPC in
the built feature set on our CI.
|
|
We used the BUILD_TESTING variable in order to indicate whether or not
tests shall be built. However this variable is used by e.g. CTest
already and there it had a different default value. Therefore we now
deprecate BUILD_TESTING and use the tests option instead.
This also fits better with our other options in terms of casing.
|
|
|
|
|
|
February 29th 2020
|
|
|
|
Cirrus CI released support for FreeBSD on their CI service in December: https://www.freebsd.org/news/newsflash.html#event20181211:01
|
