Mumble: Support for 3rd party plugins?

[Krzmbrzl]

I stumbled upon https://forums.mumble.info/viewtopic.php?t=1324&p=4728 where it was stated that a long term goal of mumble was to support some sort of plugins (in the sense that this term is being used in e.g. TeamSpeak).

What is the status of this? Is this covered by the Ice or gRPC API?
If this hasn't been worked on yet: What would be the rough outline of the work that would need to get done in order to be able to support plugins?

[Dessix]

I was just about to write one only to find that the plugin API appears to solely support position linking to games. I am trying to write an alternate input system for push to talk on Linux, and I have every step complete but "get mumble to acknowledge PTT from a plugin".

[Krzmbrzl]

Well I guess this answers the "has this been worked on yet" part with a no.

Then I'd say it's about time. I could imagine that allowing the creation of plugins for Mumble could be a big feature for it.

I was thinking that it might be smart to try to overtake the TeamSpeak API (roughly) so that it'd be as easy as possible to port existing plugins to mumble.
I never worked with the TeamSpeak API though so I can't tell you whether it's a good one or not. Thoughts and comments on this are appreciated.

[Dessix]

This would also resolve #1594, posted in 2015, by providing a means of working with the client remotely.

[Krzmbrzl]

Could you outline what kind of functionality you'd expect from a "plugin-API" in Mumble? Like what are the most basic things that'd need to be implemented?

I never created a plugin for TS or anything like it and therefore I don't know much about the details. But I'd like to get a rough overview of what needs to go into such a system.

[Krzmbrzl]

These PRs seem to be somewhat related (at least they have something to do with the existing plugin API):

• https://github.com/mumble-voip/mumble/pull/3017
• https://github.com/mumble-voip/mumble/pull/3373

[Dessix]

For the absolute basics, I think allowing push-to-talk, mic-mute, and output-mut to be modified, as well as some way to look at the current state of the client, such as whether or not it's broadcasting, (Preferably event-based / callbacks rather than polling) may be useful.

[Krzmbrzl]

I'd also like to hear the thoughts of someone who knows his/her way in the code base, in order to get an estimate on how much change would be needed in order to achieve this kind of extension.

Maybe e.g. @mkrautz or @Kissaki could state their opinion on this?

[Kissaki]

What is called "Plugin" in our code base and user interface is indeed currently only positional audio plugins - so plugins for scanning and interpreting positional and context data from games (that do not use the LinkAPI themselves).

I can’t really say I’m familiar with the code architecture to the point where I could make educated guesses or lay out a plan on what do to and how much effort it would be to support plugins.

To do that I would have to start a potentially time consuming analysis myself. Possibly our biggest problem for code and architecture encapsulation and separation of concerns is the Global class. But even that may not be as bad as it seems if it is only used for generic and simple access of other components. So I don't want to make this a definite answer either.

We have a lot of other tasks and work to do, and basically/effectively nobody working on them. So at this point we, at least as in the core team, can't work on a more generic or other endpoint plugin architecture. There are some other higher priority tasks pushing that back.

It may be not too complicated to add some plugin endpoints into component interfaces. It would still have to be a sound and tested review though before anything like that would land in master. And reviews take time as well of course.

I hope these thoughts are somewhat helpful and what you were asking for.

Regards

[Krzmbrzl]

Thank you for the insights.

The goal of this question was to verify that there is indeed no active development for implementing the plugin-interface going on. That being clarified I am currently thinking about trying to contribute such an interface myself which is why I was asking about the estimated complexity of such a task.

That an addition like this will need thorough testing goes without saying :)

I might give this a go in a month or two - we'll see

[Kissaki]

Given that the question was answered and there is nothing open to discuss for now I will close this ticket.

[davidebeatrici]

@Krzmbrzl @Dessix Thank you very much for your interest.

We're going to ditch the current API for positional audio plugins in favor of a new one made in C, mainly for ABI compatibility (e.g. plugins built with a different compiler than the one used to build Mumble). C++ can still be used to code the plugin, only the "communication" with Mumble is in C.

3017 is an initial draft; it works, but there are many things to be changed/decided yet.

I believe we can build the new API to support any plugins, not just positional audio ones.
More specifically, I'm thinking about something similar to what audio (backend) libraries provide: a callback mechanism.

Almost no changes are required in the GUI, because the universal term "Plugins" is used everywhere.
As for the code: the amount of work required depends on what we want to provide in the first version of our API.

https://github.com/mumble-voip/mumble/issues/3711#issuecomment-507841304:

For the absolute basics, I think allowing push-to-talk, mic-mute, and output-mut to be modified, as well as some way to look at the current state of the client, such as whether or not it's broadcasting, (Preferably event-based / callbacks rather than polling) may be useful.

Definitely.