Having different include files that are needed (and which are
inter-dependent) to create your own plugin, makes things harder than it
needs to be.
Therefore, all plugin header files (those for the "new" (1.4) plugin
framework anyway) have been combined into one header file. Thus,
developers now only have to download a single file and include that
instead of having to figure out what files to download and what to
include where.
Taking the chance, the version number has been removed from the header
file's name. This allows one to track changes made to the API via git
(which is not quite as easy if you create a new file every time you make
a change).
The Link plugin uses an inherently racy protocol to communicate with
applications: shared memory with no means of synchronization. This
commit makes no changes to this protocol and shouldn't break anything
that was working before. That means it doesn't eliminate race
conditions, but it does allow the plugin to work without the risk of
*data races* specifically, which are undefined behavior.
This is done by using 32-bit atomic operations to copy the LinkedMem
struct out of shared memory before reading from it. This should work
well, since every field of LinkedMem has a size that's a multiple of
32 bits, and 32-bit atomics are widely supported.
With this change, applications can avoid data races with the Link
plugin by also accessing shared memory exclusively with 32-bit atomic
operations. Applications that already work with the plugin should
continue to work.
This commit merges the two separate Link plugin implementations that
were previously used (one for Posix and one for Windows systems) and
merges them into a single one (abstracting away the platform differences
at most places).
While doing so, this commit ports the "Link" plugin to the new plugin
API (introduced with Mumble 1.4.0), such that it can make use of the
possibility to set a custom context prefix. Thus, this prefix is no
longer dependent on the plugin name (in Link's case it is set to
whatever the linked application declares as its name).
Fixes#5217
Instead of excluding all plugins but the link one on OSes other than
Windows and Linux, the new approach allows for a more granular control
by introducing a list of plugins that is supported on the different
platforms.
This replaces the globbing approach which means that new plugins have
now to be included in this list explicitly.
The advantage of this is that this allows for a much greater flexibility
for handling plugins on different OS.
Furthermore the plugin's own directory is no longer added to the
include-path by default. If a plugin wishes to do this, it should do so
explicitly. This should help make the plugins easier to move around in
the future.
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#2455Fixes#2148Fixes#1594Fixes#2051Fixes#3742Fixes#4575Fixes#4751
