Mumble rewrite #1864

Author

Owner

@felix91gr commented on GitHub (May 21, 2020):

Hey, thanks for making this thread, @Krzmbrzl ❤️

Below is what I'd like to add from what I know about Rust and from my experience by using it in big codebases.

Extra bits to your points, from what I know

Furthermore according to this article Rust achieves about the same speed as c++ applications while providing (relative?) memory safety and built-in protection against data-races.

It also provides a guarantee of no Undefined Behavior in its safe subset, which is all that you need for most applications! :)

Also it seems to be possible to include C/C++ code into Rust which might be important for including our dependencies.

Yas! Rust provides 0-cost C interfacing through FFI.

For interop with C++ though, since C++ does not have a stable ABI, it's (just as it says in the link) recommended that most C++ dependencies be called through a C API :3

Other cool things about Rust that help here:

Rust is completely cross-platform.
You can make a Rust struct have C interfaces and layout (among other things for C interop).
You can write inline assembly in it (still in nightly, but pretty solid as far as I understand).
The Rust build system (cargo) is really, really easy to use, and it streamlines the entire build process. This also makes adding dependencies a walk in the park.

My experience from using it in large codebases

I've worked as a newcomer on 4 different Rust projects: the Pathfinder crate, the Pest parser generator crate, the Clippy linter, and the Rust compiler itself.

Pathfinder is small-ish to medium sized, and Pest is medium sized. Both were a breeze to work with.

Clippy and the Rust compiler however, are big codebases. This was pretty intimidating at first, but there's three things that helped me get through them with actually very few hiccups:

The really strong type system helped me, because the types themselves act like a scaffold upon which to make changes to the code. It helped me understand where I was and how the pieces fit together.
The really good documentation infrastructure and discipline, which can be seen in action here helped me understand so much code that I was not familiar with.
The recent advances in editor integration through the rust-analyzer project make everything super transparent. You get type annotations, goto definitions, even popup doc comments. It's really really nice. It completely changed the game for me.

All in all, I think that these things make it so that participating in big projects as a newcomer is that much easier. They certainly helped me, and I'm no Rust expert.

I feel that these characteristics would help Mumble get new participants in the future without the size of the codebase being such a big barrier to them. I think it also could help ease the load of getting back into it after a long break for long-standing contributors :)

@felix91gr commented on GitHub (May 21, 2020): Hey, thanks for making this thread, @Krzmbrzl ❤️ Below is what I'd like to add from what I know about Rust and from my experience by using it in big codebases. ### Extra bits to your points, from what I know > Furthermore according to this article Rust achieves about the same speed as c++ applications while providing (relative?) memory safety and built-in protection against data-races. It also provides a guarantee of no Undefined Behavior in its [safe](https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html) subset, which is all that you need for most applications! :) > Also it seems to be possible to include C/C++ code into Rust which might be important for including our dependencies. Yas! Rust provides 0-cost C interfacing through FFI. For interop with C++ though, since C++ does not have a stable ABI, it's (just as it says in the link) recommended that most C++ dependencies be called through a C API :3 #### Other cool things about Rust that help here: * Rust is completely cross-platform. * You can make a Rust struct have C interfaces and layout (among other things for C interop). * You can write inline assembly in it (still in nightly, but pretty solid as far as I understand). * The Rust build system (cargo) is really, really easy to use, and it streamlines the entire build process. This also makes adding dependencies a walk in the park. ### My experience from using it in large codebases I've worked as a newcomer on 4 different Rust projects: the Pathfinder crate, the Pest parser generator crate, the Clippy linter, and the Rust compiler itself. Pathfinder is small-ish to medium sized, and Pest is medium sized. Both were a breeze to work with. Clippy and the Rust compiler however, are big codebases. This was pretty intimidating at first, but there's three things that helped me get through them with actually very few hiccups: * The really strong type system helped me, because the types themselves act like a scaffold upon which to make changes to the code. It helped me understand where I was and how the pieces fit together. * The really good documentation infrastructure and discipline, which can be seen in action [here](https://doc.rust-lang.org/std/) helped me understand so much code that I was not familiar with. * The recent advances in editor integration through the [rust-analyzer](https://rust-analyzer.github.io/) project make everything super transparent. You get type annotations, goto definitions, even popup doc comments. It's really really nice. It completely changed the game for me. All in all, I think that these things make it so that participating in big projects as a newcomer is that much easier. They certainly helped me, and I'm no Rust expert. I feel that these characteristics would help Mumble get new participants in the future without the size of the codebase being such a big barrier to them. I think it also could help ease the load of getting back into it after a long break for long-standing contributors :)

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 21, 2020):

If you think that you might be able to contribute, leave a comment here and I'll add you to this list here - note that this is not binding or anything. Just to get a quick overview of how many people might be contributing

I want to put my name here but I will be, for the following 4 months at least, working on my thesis so that I can finally graduate. I think I will be working mostly full-time on that, so that leaves little room for other projects.

But hey. If any of you need some help getting yourself set up with Rust, let's have a Mumble call and sort it out! :)

@felix91gr commented on GitHub (May 21, 2020): > If you think that you might be able to contribute, leave a comment here and I'll add you to this list here - note that this is not binding or anything. Just to get a quick overview of how many people might be contributing I want to put my name here but I will be, for the following 4 months at least, working on my thesis so that I can finally graduate. I think I will be working mostly full-time on that, so that leaves little room for other projects. But hey. If any of you need some help getting yourself set up with Rust, let's have a Mumble call and sort it out! :)

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 21, 2020):

Thank you for the input on Rust. Much appreciated!

@Kissaki commented on GitHub (May 21, 2020): Thank you for the input on Rust. Much appreciated!

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 21, 2020):

Drop & Rewrite

Starting with a complete rewrite is a big effort and risk one should be sure or at least aware about.

An established code-base has not only a lot of known features but also unknown features. Reaching feature parity will take a long time.

We may be in a better position here than on a big project though. Mumble is not that big of a project overall and the central functionality could be implemented without all the additions that extend it (RPC, PA, Overlay).

But still, the work is a LOT. Especially if we want to eventually implement those as well. And I am not sure we can stem that when we can barely stemp maintenance. Although this seems to have improved with more, new, active contributors in the past few months. But we can’t really necessarily plan for and with that. We have no contracts and are - for the most part - second-priority to other work and life stuff for our contributors.

Generally analysis and modularization rewrites are overall more effort but instead of a huge upfront investment and risk you have continuous improvements in milestones. You do not risk to lose it all. You move forward and users/developers gain something from it along the way rather than waiting two years before hopefully reaching feature parity. Continuous changes will also allow you to verify the changes and their impact. When the product is still in use unforeseen changes will become visible easier because you will have more users. And you can localize, see and fix them in smaller chunks.

In my professional career I had more than one “next program iteration that will replace the old” project be cancelled. Probably the most important aspect being not fast enough, visible progress (because let’s be honest it always takes longer, and secondly a rewrite takes time to have something usable beyond proof of concepts and critical paths). These were projects in a commercial settings, and while you could say this was also their downfall, I am concerned about the investment more so here were we do not have full-time contracted developers.

I hope this is not received too negatively. I don’t want to be the damper on what could be a great move forward. I appreciate the idealism and hopefulness, and I do not presume I am “correct” here necessarily, but these are the concerns we should map out, be aware of and take into account.

(From what I know) our code base quality is not very good and working through and improving is always much effort and no fun. A fresh rewrite always seems promising, and so much better. But that is no promise of success both in reaching parity nor in code quality (although I am sure it would improve).

As for time and concept and management I am also not sure when we would start tackling this. It will inevitably take time away from other projects, and will probably do so for a considerable time.

I feel like I overestimate the effort in my wording or argumentation. But it always takes longer than we feel/think at first. 🤔🤷‍♂️

Programming Language

Is this for Mumble client specifically? I think a central question then is how do we manage the GUI?

C++ I would restrict to modern C++ and not support old concepts as much as possible. C++ has the biggest userbase and potential for contributors. Would we continue to use Qt for the GUI? IDE Tooling is great. Visual Studio also supports CMake now and code suggestions.

I have worked with Go. It’s neat. I can definitely see it for server side stuff. Currently not sure about client though? GUI?

Rust I have only learned to learn more about it, not for anything significant. It may be dangerous to put too much into the most beloved language though. It may be loved for the promises, and by enthusiasts who use it for specific subsets of projects, and the sample size of users answering stack overflow questionnaires is also selective. That being said I do like the promises it makes. It has the lowest developer count and global experience of the languages, and has a central concept that developers have to learn as a barrier if they want to contribute more than very simple local changes. What about GUI?

I’ll bring up C# again as it is my currently most beloved environment. Microsoft announced a cross-platform GUI project (based on Xamarin) this week. The documentation is top notch in the industry, editable and communicative. The Tooling with Visual Studio on Windows is top (there is VS Mac, and VS Code which I have no personal experience with with C# though). The .NET ecosystem is moving forward rapidly and openly more so than any other. This November .NET 5 will unify a bunch of stuff, with more following. Performance is also great, even when it runs in an app VM and has a GC. The tooling and language would probably be easiest for beginners and new contributors to get into. I understand this is not where the our current teams expertise/experience or goal is at.

@Kissaki commented on GitHub (May 21, 2020): # Drop & Rewrite Starting with a complete rewrite is a big effort and risk one should be sure or at least aware about. An established code-base has not only a lot of known features but also unknown features. Reaching feature parity will take a long time. We may be in a better position here than on a big project though. Mumble is not that big of a project overall and the central functionality could be implemented without all the additions that extend it (RPC, PA, Overlay). But still, the work is a LOT. Especially if we want to eventually implement those as well. And I am not sure we can stem that when we can barely stemp maintenance. Although this seems to have improved with more, new, active contributors in the past few months. But we can’t really necessarily plan for and with that. We have no contracts and are - for the most part - second-priority to other work and life stuff for our contributors. Generally analysis and modularization rewrites are overall more effort but instead of a huge upfront investment and risk you have continuous improvements in milestones. You do not risk to lose it all. You move forward and users/developers gain something from it along the way rather than waiting two years before hopefully reaching feature parity. Continuous changes will also allow you to verify the changes and their impact. When the product is still in use unforeseen changes will become visible easier because you will have more users. And you can localize, see and fix them in smaller chunks. In my professional career I had more than one “next program iteration that will replace the old” project be cancelled. Probably the most important aspect being not fast enough, visible progress (because let’s be honest it always takes longer, and secondly a rewrite takes time to have something usable beyond proof of concepts and critical paths). These were projects in a commercial settings, and while you could say this was also their downfall, I am concerned about the investment more so here were we do not have full-time contracted developers. I hope this is not received too negatively. I don’t want to be the damper on what could be a great move forward. I appreciate the idealism and hopefulness, and I do not presume I am “correct” here necessarily, but these are the concerns we should map out, be aware of and take into account. (From what I know) our code base quality is not very good and working through and improving is always much effort and no fun. A fresh rewrite always seems promising, and so much better. But that is no promise of success both in reaching parity nor in code quality (although I am sure it would improve). As for time and concept and management I am also not sure when we would start tackling this. It will inevitably take time away from other projects, and will probably do so for a considerable time. I feel like I overestimate the effort in my wording or argumentation. But it always takes longer than we feel/think at first. 🤔🤷‍♂️ # Programming Language Is this for Mumble client specifically? I think a central question then is how do we manage the GUI? C++ I would restrict to modern C++ and not support old concepts as much as possible. C++ has the biggest userbase and potential for contributors. Would we continue to use Qt for the GUI? IDE Tooling is great. Visual Studio also supports CMake now and code suggestions. I have worked with Go. It’s neat. I can definitely see it for server side stuff. Currently not sure about client though? GUI? Rust I have only learned to learn more about it, not for anything significant. It may be dangerous to put too much into the most beloved language though. It may be loved for the promises, and by enthusiasts who use it for specific subsets of projects, and the sample size of users answering stack overflow questionnaires is also selective. That being said I do like the promises it makes. It has the lowest developer count and global experience of the languages, and has a central concept that developers have to learn as a barrier if they want to contribute more than very simple local changes. What about GUI? I’ll bring up C# again as it is my currently most beloved environment. Microsoft announced a cross-platform GUI project (based on Xamarin) this week. The documentation is top notch in the industry, editable and communicative. The Tooling with Visual Studio on Windows is top (there is VS Mac, and VS Code which I have no personal experience with with C# though). The .NET ecosystem is moving forward rapidly and openly more so than any other. This November .NET 5 will unify a bunch of stuff, with more following. Performance is also great, even when it runs in an app VM and has a GC. The tooling and language would probably be easiest for beginners and new contributors to get into. I understand this is not where the our current teams expertise/experience or goal is at.

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 21, 2020):

To add a bit more context and more wishful note:

We talked about whether we want to extend and promote our grumble project to be our new server. We talked about languages there as well. I would definitely like to see it being moved and pushed forward, and I would consider Go the safe choice. We also already have something. Rust would be bolder, more uncertain given how new of a language and ecosystem it is. I would be interested in a Rust project though because I would like to gain experience with it in a project setting. But I’m not sure if a productive project is the place for it. Then again it could always be replaced again later.

@Kissaki commented on GitHub (May 21, 2020): To add a bit more context and more wishful note: We talked about whether we want to extend and promote our grumble project to be our new server. We talked about languages there as well. I would definitely like to see it being moved and pushed forward, and I would consider Go the safe choice. We also already have something. Rust would be bolder, more uncertain given how new of a language and ecosystem it is. I would be interested in a Rust project though because I would like to gain experience with it in a project setting. But I’m not sure if a productive project is the place for it. Then again it could always be replaced again later.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 21, 2020):

Drop & Rewrite

You are of course correct @Kissaki that a complete rewrite does indeed bring some risks with it and time-management is definitely a concern here.
While in principle I do agree that a module-wise rewrite is a better approach for something like this, I see the problem of Mumble not having any modules in the first place. We have one big intertwined chunk of code for the client and the same for the server. And if we start to gradually replace parts of these (e.g. rewrite the audio system), we'd necessarily end up with another intertwined chunk of code as we can't just rewrite a single part to follow a modularized concept without basically rewriting all parts that are currently intertwined with it (that being basically everything at this point).
Furthermore new concepts (e.g. a centralized event hub instead of a per-object based event system) would also be hard to implement partly 🤔

I basically imagined the rewrite being done in parallel with maintaining the old code-base. Of course there's the problem of us currently not being able to fully do that without any rewrites at our hands. That'll mean that the maintaining part will definitely be reduced (e.g. no major new features - mainly bug fixes only).
My hope here would basically be to get the Mumble core rewritten somewhat soon-ish so that it'll be usable for users that only use Mumble for VoiP (no overlay, no PA, etc).

Furthermore I think if we don't invest into a rewrite now and focus on maintaining the old code base, I'm afraid the trend will continue and the number of active devs will decline simply because it is that hard to get into the code base. In the worst case this could lead to a slow death of Mumble due to lack of developers.
And once that happened, I think it'll be even harder to motivate people to help with a rewrite/refactor.

I hope this is not received too negatively. I don’t want to be the damper on what could be a great move forward.

No worries. It is very important to really think this through because you're absolutely right: It'll be a big investment. Critical thoughts are always welcome (and important!).

Programming Language

Is this for Mumble client specifically? I think a central question then is how do we manage the GUI?

I was more thinking this to be a general discussion about client and server. One important goal I'd have with a rewrite would be a clear separation between frontend and backend code in the client. The backend should have a nice C API that should allow various frontends to easily connect to it. That way it should also be possible to use whatever language for the frontend (maybe even something Python?) so we can make a choice there based on the kind of UI toolkit we want to use.

It may be dangerous to put too much into the most beloved language though

Absolutely. we should definitely not count on that too much. Nonetheless it's something to consider.

It has the lowest developer count and global experience of the languages, and has a central concept that developers have to learn as a barrier if they want to contribute more than very simple local changes.

This might be true (do you happen to have a reference on that with more details?) but at least from what I heard over the last years, it also seems to steadily gain importance in the industry. I should not however that I'm not "in the industry" myself so maybe that's just wrong. I'm also trying to find some numbers for this but no luck so far...

I have worked with Go. It’s neat. I can definitely see it for server side stuff. Currently not sure about client though?

I'm somewhat skeptical when it comes to languages with a GC. Given that one of Mumble's main selling points is low latency I imagine it to be very important for the critical code to run as fast as possible. And all benchmarks I have encountered so far showed that Go is still several orders slower than e.g. C++ or Rust (see e.g. this benchmark).

I’ll bring up C# again as it is my currently most beloved environment.

I never worked with C# but still I kinda dislike it. That's probably mostly because it's developed by Microsoft which I personally don't really embrace. On the other hand though this is obviously no proper reasoning against it.
The only real concern I have with that is that it might be too slow. Iirc it's basically on the same level as Java, isn't it?

The tooling and language would probably be easiest for beginners and new contributors to get into.

This is of course a valid argument. I think Rust isn't too bad on that end (the tooling) either, though 🤔

@Krzmbrzl commented on GitHub (May 21, 2020): # Drop & Rewrite You are of course correct @Kissaki that a complete rewrite does indeed bring some risks with it and time-management is definitely a concern here. While in principle I do agree that a module-wise rewrite is a better approach for something like this, I see the problem of Mumble not having any modules in the first place. We have one big intertwined chunk of code for the client and the same for the server. And if we start to gradually replace parts of these (e.g. rewrite the audio system), we'd necessarily end up with another intertwined chunk of code as we can't just rewrite a single part to follow a modularized concept without basically rewriting all parts that are currently intertwined with it (that being basically everything at this point). Furthermore new concepts (e.g. a centralized event hub instead of a per-object based event system) would also be hard to implement partly :thinking: I basically imagined the rewrite being done in parallel with maintaining the old code-base. Of course there's the problem of us currently not being able to fully do that without any rewrites at our hands. That'll mean that the maintaining part will definitely be reduced (e.g. no major new features - mainly bug fixes only). My hope here would basically be to get the Mumble core rewritten somewhat soon-ish so that it'll be usable for users that only use Mumble for VoiP (no overlay, no PA, etc). Furthermore I think if we don't invest into a rewrite now and focus on maintaining the old code base, I'm afraid the trend will continue and the number of active devs will decline simply because it is that hard to get into the code base. In the worst case this could lead to a slow death of Mumble due to lack of developers. And once that happened, I think it'll be even harder to motivate people to help with a rewrite/refactor. > I hope this is not received too negatively. I don’t want to be the damper on what could be a great move forward. No worries. It is very important to really think this through because you're absolutely right: It'll be a big investment. Critical thoughts are always welcome (and important!). # Programming Language > Is this for Mumble client specifically? I think a central question then is how do we manage the GUI? I was more thinking this to be a general discussion about client and server. One important goal I'd have with a rewrite would be a clear separation between frontend and backend code in the client. The backend should have a nice C API that should allow various frontends to easily connect to it. That way it should also be possible to use whatever language for the frontend (maybe even something Python?) so we can make a choice there based on the kind of UI toolkit we want to use. > It may be dangerous to put too much into the most beloved language though Absolutely. we should definitely not count on that too much. Nonetheless it's something to consider. > It has the lowest developer count and global experience of the languages, and has a central concept that developers have to learn as a barrier if they want to contribute more than very simple local changes. This might be true (do you happen to have a reference on that with more details?) but at least from what I heard over the last years, it also seems to steadily gain importance in the industry. I should not however that I'm not "in the industry" myself so maybe that's just wrong. I'm also trying to find some numbers for this but no luck so far... > I have worked with Go. It’s neat. I can definitely see it for server side stuff. Currently not sure about client though? I'm somewhat skeptical when it comes to languages with a GC. Given that one of Mumble's main selling points is low latency I imagine it to be very important for the critical code to run as fast as possible. And all benchmarks I have encountered so far showed that Go is still several orders slower than e.g. C++ or Rust (see e.g. [this benchmark](https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html)). > I’ll bring up C# again as it is my currently most beloved environment. I never worked with C# but still I kinda dislike it. That's probably mostly because it's developed by Microsoft which I personally don't really embrace. On the other hand though this is obviously no proper reasoning against it. The only real concern I have with that is that it might be too slow. Iirc it's basically on the same level as Java, isn't it? > The tooling and language would probably be easiest for beginners and new contributors to get into. This is of course a valid argument. I think Rust isn't too bad on that end (the tooling) either, though :thinking:

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 21, 2020):

In regards to Rust being the most loved language: I just found this StackOverflow blog in which it is stated that Rust has been the most loved language for the last 4 years.
The criticism about SO not being the perfect mapping of how things really are still applies of course but that's still an interesting achievement...

EDIT: That blog post is a good read for anyone not too familiar with Rust in any case. Very informative.

@Krzmbrzl commented on GitHub (May 21, 2020): In regards to Rust being the most loved language: I just found [this StackOverflow blog](https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/) in which it is stated that Rust has been the most loved language *for the last 4 years*. The criticism about SO not being the perfect mapping of how things really are still applies of course but that's still an interesting achievement... EDIT: That blog post is a good read for anyone not too familiar with Rust in any case. Very informative.

deekerman commented

Author

Owner

@timokoesters commented on GitHub (May 21, 2020):

Rust also has excellent documentation (the book, std lib, docs.rs) and a pretty active discord channel

@timokoesters commented on GitHub (May 21, 2020): Rust also has excellent documentation (the book, std lib, docs.rs) and a pretty active discord channel

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 21, 2020):

Having protobuf for our protocol provides a great baseline and definition of what we work with and base on. I think we should be able to move forward well with a new project.

I certainly have no overview of the code base. And a drop and rewrite may very well, or probably is the best way forward. Even if we lose some features - for a while or forever - it would still be a plus if the project moves forward through it and becomes more maintainable and extensible.

@Kissaki commented on GitHub (May 21, 2020): Having protobuf for our protocol provides a great baseline and definition of what we work with and base on. I think we should be able to move forward well with a new project. I certainly have no overview of the code base. And a drop and rewrite may very well, or probably is the best way forward. Even if we lose some features - for a while or forever - it would still be a plus if the project moves forward through it and becomes more maintainable and extensible.

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 21, 2020):

So you are suggesting not just a separating of client and server, but also client frontend/GUI and backend/functional library. Which is fair I think. It may be a bit more work, but should definitely be worth it. We have libmumble currently, but a unified base library that receives primary maintenance will be much better and versatile for users.

So the separation targets would be

Protocol definition (including protobuf message definitions)
Server
Client library
Server library

I guess it would make sense to share networking code between client and server to a degree. So maybe then it would be

protocol
networking library
server
client control library
client gui

@Kissaki commented on GitHub (May 21, 2020): So you are suggesting not just a separating of client and server, but also client frontend/GUI and backend/functional library. Which is fair I think. It may be a bit more work, but should definitely be worth it. We have libmumble currently, but a unified base library that receives primary maintenance will be much better and versatile for users. So the separation targets would be * Protocol definition (including protobuf message definitions) * Server * Client library * Server library I guess it would make sense to share networking code between client and server to a degree. So maybe then it would be * protocol * networking library * server * client control library * client gui

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 21, 2020):

it also seems to steadily gain importance in the industry. I should not however that I'm not "in the industry" myself so maybe that's just wrong

Even within the industry you will always have local phenomenon. It is hard to measure these. In that sense stack overflow may be one of the best overviews aside from dedicated representative studies.

I would actually like to take the leap and work with Rust. It holds great promises. It is certainly the top candidate if you consider performance and safety to the very last bit - at least judging from technical setup. My main concern right now would be GUI but if we want to support a C ABI/interface (which rust supports [well?]) then we could go back to a multiplatform Qt GUI for the client GUI if we find nothing better and do not want to split between platforms.

Rust is stable enough for production. “Gaining traction” is a relative term and doesn’t say much more besides a trend. And there have been technological trends that were just hypes. Sometimes they stick, other times they stay niche. But I think the promises rust makes are worth investing. At the very least to a prototype stage where we can make more educated decisions. And it is prevalent enough to call it a (currently growing) niche and established enough to invest.

@Kissaki commented on GitHub (May 21, 2020): > it also seems to steadily gain importance in the industry. I should not however that I'm not "in the industry" myself so maybe that's just wrong Even within the industry you will always have local phenomenon. It is hard to measure these. In that sense stack overflow may be one of the best overviews aside from dedicated representative studies. I would actually like to take the leap and work with Rust. It holds great promises. It is certainly the top candidate if you consider performance and safety to the very last bit - at least judging from technical setup. My main concern right now would be GUI but if we want to support a C ABI/interface (which rust supports [well?]) then we could go back to a multiplatform Qt GUI for the client GUI if we find nothing better and do not want to split between platforms. Rust is stable enough for production. “Gaining traction” is a relative term and doesn’t say much more besides a trend. And there have been technological trends that were just hypes. Sometimes they stick, other times they stay niche. But I think the promises rust makes are worth investing. At the very least to a prototype stage where we can make more educated decisions. And it is prevalent enough to call it a (currently growing) niche and established enough to invest.

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 21, 2020):

Rust also has excellent documentation (the book, std lib, docs.rs) and a pretty active discord channel

I loved the error messages when I was using it. :)

@Kissaki commented on GitHub (May 21, 2020): > Rust also has excellent documentation (the book, std lib, docs.rs) and a pretty active discord channel I loved the error messages when I was using it. :)

deekerman commented

Author

Owner

@Avatat commented on GitHub (May 21, 2020):

@Krzmbrzl, sorry for being silent for a few days, but I'm alive and please add me to the list :D
I would love to do server/crypto/container related stuff, with your (and @davidebeatrici 👋 )help!

(I have no access to IRC through Monday)

@Avatat commented on GitHub (May 21, 2020): @Krzmbrzl, sorry for being silent for a few days, but I'm alive and please add me to the list :D I would love to do server/crypto/container related stuff, with your (and @davidebeatrici 👋 )help! (I have no access to IRC through Monday)

deekerman commented

Author

Owner

@toby63 commented on GitHub (May 21, 2020):

Very promising idea 👍

Disclaimer: I am not a programmer, so maybe I just talk nonsense 😄

I see some clear Advantages:

up-to-date code
developers knowing about how the code works
potencial for better documentation

Still there are some open questions:
Is there real potencial:

for significantly less code?
for much better structure?
for better functionality (performance, security etc.)?

You know the point I am thinking of is: if not, then maybe the advantage is maybe too small(?) and the risk to high?

Also:

Is there enough knowledge for a rewrite (no offence, but I noticed that some parts (like audio etc.) seem to be "unknown territory" for many)?

Some specifics:
@Kissaki mentioned:

I’ll bring up C# again as it is my currently most beloved environment. Microsoft announced a cross-platform GUI project (based on Xamarin) this week.

I advice against that.
You never know how long the fake-love of microsoft for linux will exist and then suddenly the support is dropped.

@Krzmbrzl mentioned:

clear separation between frontend and backend code in the client.

Sounds good 👍.

Some other points and ideas to add:

What dependencies do you want to keep/add/remove?
(I might be wrong about it, but that might be a point in picking a programming language etc. as well (or not?))
- I see in #4150 for example, that Qt still seems to be a good option for multi-OS-support of "core"-features, while at the same time I read that you want to move away from it.
- Audio: We just had very much discussion about the audio, so it would be good to make decisions for that as well, like:
  - what audio-filter/echo-cancel-libraries should be used?
- Encryption: #3918 #1813
- GUI (@Krzmbrzl mentioned that it could rely on other coding languages (and probably librarys etc.) because of the intended frontend/backend-seperation, so there could be more space for implementation options)
Overall functionality principle of mumble:
I read some interesting things about:
- federation: In this case I mean the idea to combine servers or data ("adress books"/chat logs/channels) from the servers
- webrtc: #3561
  So that might be options to think about.
Better functionality:
- better chat (chat windows, seperation of user/channel/server-chat, markdown-support, integration of matrix-extension #3791(?) etc.)
better GUI (more customizable #3608 etc.)

@toby63 commented on GitHub (May 21, 2020): Very promising idea :+1: Disclaimer: I am not a programmer, so maybe I just talk nonsense :smile: I see some clear Advantages: * up-to-date code * developers knowing about how the code works * potencial for better documentation Still there are some open questions: Is there real potencial: * for significantly less code? * for much better structure? * for better functionality (performance, security etc.)? You know the point I am thinking of is: if not, then maybe the advantage is maybe too small(?) and the risk to high? Also: * Is there enough knowledge for a rewrite (no offence, but I noticed that some parts (like audio etc.) seem to be "unknown territory" for many)? **Some specifics:** @Kissaki mentioned: > I’ll bring up C# again as it is my currently most beloved environment. Microsoft announced a cross-platform GUI project (based on Xamarin) this week. I advice against that. You never know how long the fake-love of microsoft for linux will exist and then suddenly the support is dropped. @Krzmbrzl mentioned: > clear separation between frontend and backend code in the client. Sounds good :+1:. **Some other points and ideas to add:** * What dependencies do you want to keep/add/remove? (I might be wrong about it, but that might be a point in picking a programming language etc. as well (or not?)) * I see in #4150 for example, that Qt still seems to be a good option for multi-OS-support of "core"-features, while at the same time I read that you want to move away from it. * Audio: We just had very much discussion about the audio, so it would be good to make decisions for that as well, like: * what audio-filter/echo-cancel-libraries should be used? * Encryption: #3918 #1813 * GUI (@Krzmbrzl mentioned that it could rely on other coding languages (and probably librarys etc.) because of the intended frontend/backend-seperation, so there could be more space for implementation options) * Overall functionality principle of mumble: I read some interesting things about: * federation: In this case I mean the idea to combine servers or data ("adress books"/chat logs/channels) from the servers * webrtc: #3561 So that might be options to think about. * Better functionality: * better chat (chat windows, seperation of user/channel/server-chat, markdown-support, integration of matrix-extension #3791(?) etc.) * better GUI (more customizable #3608 etc.)

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 21, 2020):

for significantly less code?

Probably not. But the amount of code is less of a problem (many feature inevitably lead to a lot of code). It's the structure, documentation and overall readability of the code.

for much better structure?

I'm pretty sure on this one as right now there isn't a whole lot of structure in the code-base to begin with.

for better functionality (performance, security etc.)?

That I don't know. Maybe, but then again I think performance and security aren't really issues Mumble is currently facing. I think that if we get the same performance & security as we currently have, that's fine.

You know the point I am thinking of is: if not, then maybe the advantage is maybe too small(?) and the risk to high?

The main reason for the rewrite is to facility maintainability and extendability. Without these it'll be very hard for existing devs to continue working on the code and even harder for new devs to join the team. This will probably lead to a slow decline in the number of devs anhd ultimately into a development freeze.

Is there enough knowledge for a rewrite (no offence, but I noticed that some parts (like audio etc.) seem to be "unknown territory" for many)?

I'm optimistic about this one. @davidebeatrici for instance knows the audio code and if e.g. people like @fedetft might also review or even contribute code, we're on the safe side here.
Furthermore we can also look stuff up. The main problem with the current audio code is less that nobody knows how audio processing works in principle (though for instance I indeed don't xD) but more that it's really hard to grasp how it's implemented in Mumble specifically (what are the relations between different classes, what is the path audio usually takes, etc.).

What dependencies do you want to keep/add/remove?

I think this point will be solved automatically during the rewrite process. The dependencies we still need will be included and the ones that we don't really need anymore probably won't.

(I might be wrong about it, but that might be a point in picking a programming language etc. as well (or not?))

Not really no. Most (if not all) dependencies for stuff like audio processing are C libraries that can be interfaced and included from basically any programming language (long live the C API :D)

Overall functionality principle of mumble:

Although valid, this seems to be mostly stuff that could also be added/cahnged later on as an extension and are not vital to the basic functionality. Thus I'd postpone the discussion about that until we have a working prototype.
Of course the aim is to write the new library in a way that makes it easy to extend on it and change how stuff works (aka. facilitates refactoring).

@Krzmbrzl commented on GitHub (May 21, 2020): > for significantly less code? Probably not. But the amount of code is less of a problem (many feature inevitably lead to a lot of code). It's the structure, documentation and overall readability of the code. > for much better structure? I'm pretty sure on this one as right now there isn't a whole lot of structure in the code-base to begin with. > for better functionality (performance, security etc.)? That I don't know. Maybe, but then again I think performance and security aren't really issues Mumble is currently facing. I think that if we get the same performance & security as we currently have, that's fine. > You know the point I am thinking of is: if not, then maybe the advantage is maybe too small(?) and the risk to high? The main reason for the rewrite is to facility maintainability and extendability. Without these it'll be very hard for existing devs to continue working on the code and even harder for new devs to join the team. This will probably lead to a slow decline in the number of devs anhd ultimately into a development freeze. > Is there enough knowledge for a rewrite (no offence, but I noticed that some parts (like audio etc.) seem to be "unknown territory" for many)? I'm optimistic about this one. @davidebeatrici for instance knows the audio code and if e.g. people like @fedetft might also review or even contribute code, we're on the safe side here. Furthermore we can also look stuff up. The main problem with the current audio code is less that nobody knows how audio processing works in principle (though for instance I indeed don't xD) but more that it's really hard to grasp how it's implemented in Mumble specifically (what are the relations between different classes, what is the path audio usually takes, etc.). > What dependencies do you want to keep/add/remove? I think this point will be solved automatically during the rewrite process. The dependencies we still need will be included and the ones that we don't really need anymore probably won't. > (I might be wrong about it, but that might be a point in picking a programming language etc. as well (or not?)) Not really no. Most (if not all) dependencies for stuff like audio processing are C libraries that can be interfaced and included from basically any programming language (long live the C API :D) > Overall functionality principle of mumble: Although valid, this seems to be mostly stuff that could also be added/cahnged later on as an extension and are not vital to the basic functionality. Thus I'd postpone the discussion about that until we have a working prototype. Of course the aim is to write the new library in a way that makes it easy to extend on it and change how stuff works (aka. facilitates refactoring).

deekerman commented

Author

Owner

@ghost commented on GitHub (May 21, 2020):

Drop & Rewrite

I recommend to read https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
If nobody know how audio works, then I'm certain new bugs will be introduced.
That's @Kissaki 's point of view basically. And I would opt this way, because imho Mumble needs features now, not after few years later.

Generally analysis and modularization rewrites are overall more effort but instead of a huge upfront investment and risk you have continuous improvements in milestones

Rewrite can make sense, but only as @Krzmbrzl stated, to split client's core functionality and GUI. I'm worried however that may end up like with microservices — in Mumble case, monolith in C++ seems to be better.

Programming Language

I'm sure writing in Rust is exciting, learning cool things is always fun, but I doubt it'll gather new developers for Mumble project. Digging into code may be harder due to lack of battle-tested IDE. If backend is a Rust/Go and client frontend would be PyQt, it'll create new issues:

it'll double work (make change in backend, then make a proper RPC call from frontend;
two programming languages — two IDEs;
what about debugging?
what about Mumble Client's license? PyQT is GPL only.

@ghost commented on GitHub (May 21, 2020): # Drop & Rewrite I recommend to read https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ If nobody know how audio works, then I'm certain new bugs will be introduced. That's @Kissaki 's point of view basically. And I would opt this way, because imho Mumble needs features now, not after few years later. > Generally analysis and modularization rewrites are overall more effort but instead of a huge upfront investment and risk you have continuous improvements in milestones Rewrite can make sense, but only as @Krzmbrzl stated, to split client's core functionality and GUI. I'm worried however that may end up like with microservices — in Mumble case, monolith in C++ seems to be better. # Programming Language I'm sure writing in Rust is exciting, learning cool things is always fun, but I doubt it'll gather new developers for Mumble project. Digging into code may be harder due to lack of battle-tested IDE. If backend is a Rust/Go and client frontend would be PyQt, it'll create new issues: - it'll double work (make change in backend, then make a proper RPC call from frontend; - two programming languages — two IDEs; - what about debugging? - what about Mumble Client's license? PyQT is GPL only.

deekerman commented

Author

Owner

@ghost commented on GitHub (May 21, 2020):

@Krzmbrzl
You need take this benchmark with a grain of salt, for example in binarytrees benchmark Go lang is 3 times slower than Java. Why? Because it's basically benchmarks GC, but Java and Go have different goals - Java GC is optimized for throughput, Go for latency (description of benchmark) . But speed is one metric, memory is the other one — if service usage is relatively low, I will opt for Python. While a lot slower, it uses much less memory.
Take a look on that https://github.com/ixy-languages/ixy-languages benchmark. Go and C# are quite fast there.

@ghost commented on GitHub (May 21, 2020): @Krzmbrzl You need take this benchmark with a grain of salt, for example in [binarytrees benchmark](https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html) Go lang is 3 times slower than Java. Why? Because it's basically benchmarks GC, but Java and Go have different goals - Java GC is optimized for throughput, Go for latency ([description of benchmark]( https://benchmarksgame-team.pages.debian.net/benchmarksgame/description/binarytrees.html#binarytrees)) . But speed is one metric, memory is the other one — if service usage is relatively low, I will opt for Python. While a lot slower, it uses much less memory. Take a look on that https://github.com/ixy-languages/ixy-languages benchmark. Go and C# are quite fast there.

deekerman commented

Author

Owner

@streaps commented on GitHub (May 21, 2020):

What about Vala and/or GObject C for the backend?

@streaps commented on GitHub (May 21, 2020): What about Vala and/or GObject C for the backend?

deekerman commented

Author

Owner

@fedetft commented on GitHub (May 21, 2020):

Given that I'm new to Mumble and recently started to look into its code for the first time, I think I can leave my 2 cents.

Language

I'd stick with C++, but of course use modern C++.

There are parts that mumble relies on that you definitely don't want to rewrite. The codecs, dsp stuff and GUI toolkit. These work well with C++, with other languages, not so much.

Rust can easily call C, but not C++. What if you want to use webrtc for audio input? That's C++. Qt? C++ as well, and Rust as far as I know doesn't have a well established GUIs toolkit.

Go is even worse in interoperability with C code, as it's a garbage collected language, and moving pointers between a GC and non GC world may easily cause bugs. It also does funny things with the stack due to the closures and the like. Also, the GUI toolkit issue is the same as with Rust.

You may think that the problem can be solved with automated tools that do the binding between the new and old language, but I've had bad experience with those. I once worked on a project that was half C++ and half python and used swig to make the C++ code available to python. When tasked with making it run on the newest Ubuntu, the thing started segfaulting and the segfault was in the swig autogenerated code, and no one in the team could understand that messy autogenerated stuff. Not fun.

The problem with the current codebase

I only have limited experience with the Mumble codebase, but by what I could see, the problem is that Mumble not only isn't written in modern C++, it looks written in C++ by a C programmer which did this as his/her first C++ project because Qt was in C++.

The whole AudioInput class is a god object. It tries to be and do everything. The queue for the audio canceller wasn't in a separate class, it was implemented with fields of AudioInput and the logic sprinkled around its methods. The OS-dependent driver isn't a separate class, it's a derived class of AudioInput!
No attention is paid to minimizing the scope of variables. When a programmer joins a project and wants to understand what a variable does, it helps that it's scope is as small as possible, but no, in AudioInput most buffers are declared at class-level, allocated in the constructor and deallocated in the destructor. Functions that should take parameters don't have any and go get their parameters from the class-level fields used as if they're global variables.
It also shows the signs of people tacking on new features without them (or maintainers) integrating them. Have a look at how the voice activity is implemented. In the UI it's a 3 option combobox, in the code?
enum AudioTransmit { Continuous, VAD, PushToTalk };
That's good.
But what about the echo canceller? It is too a 3 way combobox in the UI, but in code

bool bEcho;
bool bEchoMulti;

Why 2 bool and not and enum. And why AudioInput declares those:

SpeexEchoState *sesEcho;
bool bEchoMulti;

and checks for sesEcho pointer being null or not to see wheter echo cancel is active, and there's a separate bool for whether it's mixed or multichannel.
I guess multichannel echo was tacked on years later...
An what about RNNoise? Good idea adding it, but why enabling it doesn't disable libspeexdsp's noise canceller. And why RNNoise is executed before the echo canceller, while speex's noise canceller after? No one could tell me why, so I guess it was tacked on without much thought.

I could go on, but I guess the point is clear.

What I would do (if I had the time to do it...)

For strange as it would seem, I would not rewrite it as a first option, but heavily refactor it.
Why? Other than old bugs, it contains also old wisdom. Getting something to work on linux/windows/mac isn't that easy. Obscure corner cases that may have been dealt with may need to be rediscovered again from scratch.
Besides, it's a huge effort to rewrite (and maintain the old version till the rewrite is done too!), who is willing to spend the time for that?

If you really want to rewrite it, at least I'd use a "tick tock approach".

First write from scratch a new "mumble core", just the network and audio part. I'd use boost asio for the network, and webrtc for the audio. All written in modern C++, and no Qt allowed here. Plan ahead so that the stuff compiles also on Android and iOS, uses stereo for the audio playback, etc. It's the time to make it future proof, and even if some feature isn't implemented right now, make sure it can be added without another rewrite. But also make sure to give the project a scope and stick to that. Trying to make the scope too wide may risk ruining the project. Video calls? Are you sure you want that? That's a ton of work, and for what? To become a zoom competitor? That's not what mumble is good at.

When it's ready, patch the old UI so that it calls the new core so you get people to use it and report bugs. In the meantime, start rewriting the UI. I'd stick to Qt for the desktop, as it's the most well established cross platform GUI toolkit and there's no contest here. But also do JNI bindings of the core (by hand, so no risk of finding yourself with unmaintainable code), and make an UI for smartphones too.

@fedetft commented on GitHub (May 21, 2020): Given that I'm new to Mumble and recently started to look into its code for the first time, I think I can leave my 2 cents. ## Language I'd stick with C++, but of course use modern C++. There are parts that mumble relies on that you definitely don't want to rewrite. The codecs, dsp stuff and GUI toolkit. These work well with C++, with other languages, not so much. Rust can easily call C, but not C++. What if you want to use webrtc for audio input? That's C++. Qt? C++ as well, and Rust as far as I know doesn't have a well established GUIs toolkit. Go is even worse in interoperability with C code, as it's a garbage collected language, and moving pointers between a GC and non GC world may easily cause bugs. It also does funny things with the stack due to the closures and the like. Also, the GUI toolkit issue is the same as with Rust. You may think that the problem can be solved with automated tools that do the binding between the new and old language, but I've had bad experience with those. I once worked on a project that was half C++ and half python and used swig to make the C++ code available to python. When tasked with making it run on the newest Ubuntu, the thing started segfaulting and the segfault was in the swig autogenerated code, and no one in the team could understand that messy autogenerated stuff. Not fun. ## The problem with the current codebase I only have limited experience with the Mumble codebase, but by what I could see, the problem is that Mumble not only isn't written in modern C++, it looks written in C++ by a C programmer which did this as his/her first C++ project because Qt was in C++. The whole AudioInput class is a god object. It tries to be and do everything. The queue for the audio canceller wasn't in a separate class, it was implemented with fields of AudioInput and the logic sprinkled around its methods. The OS-dependent driver isn't a separate class, it's a **derived** class of AudioInput! No attention is paid to minimizing the scope of variables. When a programmer joins a project and wants to understand what a variable does, it helps that it's scope is as small as possible, but no, in AudioInput most buffers are declared at class-level, allocated in the constructor and deallocated in the destructor. Functions that should take parameters don't have any and go get their parameters from the class-level fields used as if they're global variables. It also shows the signs of people tacking on new features without them (or maintainers) integrating them. Have a look at how the voice activity is implemented. In the UI it's a 3 option combobox, in the code? `enum AudioTransmit { Continuous, VAD, PushToTalk };` That's good. But what about the echo canceller? It is too a 3 way combobox in the UI, but in code ``` bool bEcho; bool bEchoMulti; ``` Why 2 bool and not and enum. And why AudioInput declares those: ``` SpeexEchoState *sesEcho; bool bEchoMulti; ``` and checks for `sesEcho` pointer being null or not to see wheter echo cancel is active, and there's a separate bool for whether it's mixed or multichannel. I guess multichannel echo was tacked on years later... An what about RNNoise? Good idea adding it, but why enabling it doesn't disable libspeexdsp's noise canceller. And why RNNoise is executed before the echo canceller, while speex's noise canceller after? No one could tell me why, so I guess it was tacked on without much thought. I could go on, but I guess the point is clear. ## What I would do (if I had the time to do it...) For strange as it would seem, I would not rewrite it as a first option, but heavily refactor it. Why? Other than old bugs, it contains also old wisdom. Getting something to work on linux/windows/mac isn't that easy. Obscure corner cases that may have been dealt with may need to be rediscovered again from scratch. Besides, it's a huge effort to rewrite (and maintain the old version till the rewrite is done too!), who is willing to spend the time for that? If you really want to rewrite it, at least I'd use a "tick tock approach". First write from scratch a new "mumble core", just the network and audio part. I'd use boost asio for the network, and webrtc for the audio. All written in modern C++, and no Qt allowed here. Plan ahead so that the stuff compiles also on Android and iOS, uses stereo for the audio playback, etc. It's the time to make it future proof, and even if some feature isn't implemented right now, make sure it can be added without another rewrite. But also make sure to give the project a scope and stick to that. Trying to make the scope too wide may risk ruining the project. Video calls? Are you sure you want that? That's a **ton** of work, and for what? To become a zoom competitor? That's not what mumble is good at. When it's ready, patch the old UI so that it calls the new core so you get people to use it and report bugs. In the meantime, start rewriting the UI. I'd stick to Qt for the desktop, as it's the most well established cross platform GUI toolkit and there's no contest here. But also do JNI bindings of the core (by hand, so no risk of finding yourself with unmaintainable code), and make an UI for smartphones too.

deekerman commented

Author

Owner

@fedetft commented on GitHub (May 21, 2020):

Ah, and be ready to debug stuff that doesn't work only on the computer of some users, as I'm doing now with the echo canceller and @Krzmbrzl's PC...

@fedetft commented on GitHub (May 21, 2020): Ah, and be ready to debug stuff that doesn't work only on the computer of **some** users, as I'm doing now with the echo canceller and @Krzmbrzl's PC...

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 21, 2020):

@Reikion

If nobody know how audio works, then I'm certain new bugs will be introduced.

One nitpick here: Mumble appears to have tests. I don't know how good the test suite is, but with good enough testing, you can mitigate this issue.

I'm sure that most of those tests won't run on whatever new platform is used for a rewrite. Even if it's re-made in C++ they might not run, because of how siloed the testing frameworks are for C and C++. But! The logic is there. Those tests can be translated into the future. And if the tests are decent enough, I think that we might have a shot at a rewrite without compromising the integrity of the audio solution 🙂

@felix91gr commented on GitHub (May 21, 2020): @Reikion > If nobody know how audio works, then I'm certain new bugs will be introduced. One nitpick here: Mumble [appears to have tests](https://github.com/mumble-voip/mumble/tree/master/src/tests). I don't know how good the test suite is, but with good enough testing, you can mitigate this issue. I'm sure that most of those tests won't run on whatever new platform is used for a rewrite. Even if it's re-made in C++ they might not run, because of how siloed the testing frameworks are for C and C++. But! The logic is there. Those tests can be translated into the future. And if the tests are decent enough, I think that we might have a shot at a rewrite without compromising the integrity of the audio solution 🙂

deekerman commented

Author

Owner

@ghost commented on GitHub (May 21, 2020):

I would like to both echo some sentiments and provide some ideas based on some discoveries I made during my exposure to the dependencies, and thoughts I had while working with @davidebeatrici on the CMake project. I welcome any feedback or criticisms.

One of the discussions we had during our meeting was backwards compatibility, but I think we briefly touched on security considerations. The speex and celt dependencies are no longer developed or supported by xiph. Their site tells you to migrate away to opus for both codecs. As of the last review and test build, these features cannot be disabled because the build will not be successful. This would be mitigated by a more modularized approach. I attempted to remove speex related types from the source just to see if this could be accomplished and there was a healthy amount of frustration as a result. We need a way to offline dependencies that may lose support and possibly become insecure as part of any future proofing strategy. I think the core components of the project should stand on their own and we can lay modules on top of or remove them, as needed. This also allows more devs and dev teams to build on the framework both for us and their own projects. This promotes growth and could lead to more contributors, projects that use our code, and better visibility for things like donations.

It's important to look at how features have been added in the past and how we should add them in the future. Most of my educational and professional experience has been with C# for concepts in OOP and C++ with regard to game engines or simulation. They are vastly different paradigms when it comes to writing code, and the luster of OOP begins to dissolve the closer you get to game dev. I think that as we start to decide between refactor and rewrite that we start looking at how things can be done and plan to implement them in a way that makes the transition possible to a fresh code base. This way we make progress even if a rewrite isn't possible. The important first question is, "Can we reasonably refactor?"

I would not be opposed to another language, like .net (core). Since it is compiled into an intermediate language there are a lot of different things you can throw on top of it, including C++. It is also open source. I tend to look at newer languages with some cautious reluctance. This is not to say that new languages shouldn't be considered, but things like governance, licensing, and target should also be part of the decision making process. I see several job alerts for people with experience in Rust and Go, but I also recall the same skill requirement trend over Scala. I guess, I am saying that a balance should be struck between longevity of the language and ease of use for newcomers. I am open to learning a language that promotes these metrics.

With regard to UI/UX, my impression based on the wealth of target platforms would be to consider using native platform look and feel. Unless we are attempting to make the product look better than what would be part of the system then we are losing the ability to provide an experience that appeals to users. @Kissaki brought up Xamarin which bridges that gap quite well. One of the benefits of the modular approach would be to give devs the option of a UI agnostic set of deliverables. As it is now, if we aren't bringing anything feature rich to Qt UI elements in terms of theming or customization then it may be more than we actually need. With their current requirements for obtaining the source becoming more intrusive it might be time to at least consider alternatives. I'm sure there are better network and translation libraries we could use.

I have also seen some comments on product competition, including the addition of other features not part of the core set, such as video chat. I don't think we should discourage others who want to use the core framework to add in features like that. We should provide a way for them to plug in features if they choose to. I don't think Mumble should be more than what it is. I think it should do what it does better than other programs like it. Mumble was something I discovered because I didn't like TeamSpeak or Ventrillo, mostly because of user count restrictions. Discord is another failure of a perfectly good open source opportunity that I hoped Matrix would make up for. In some ways, it does. One of the biggest realizations I recently had during the meeting was the fact we don't use what we make as our main source of communication. It speaks volumes to the faith we have in what we are doing if we are using the product we make to collaborate on the product. I realize that Matrix is hosted by someone else, but maybe that is a consideration of where we could go with the project.

I realize not all of this has to do with development of Mumble, but I think some of these concepts are worth putting out there for discussion as part of where we are trying to go with the project.

@ghost commented on GitHub (May 21, 2020): I would like to both echo some sentiments and provide some ideas based on some discoveries I made during my exposure to the dependencies, and thoughts I had while working with @davidebeatrici on the CMake project. I welcome any feedback or criticisms. One of the discussions we had during our meeting was backwards compatibility, but I think we briefly touched on security considerations. The speex and celt dependencies are no longer developed or supported by xiph. Their site tells you to migrate away to opus for both codecs. As of the last review and test build, these features cannot be disabled because the build will not be successful. This would be mitigated by a more modularized approach. I attempted to remove speex related types from the source just to see if this could be accomplished and there was a healthy amount of frustration as a result. We need a way to offline dependencies that may lose support and possibly become insecure as part of any future proofing strategy. I think the core components of the project should stand on their own and we can lay modules on top of or remove them, as needed. This also allows more devs and dev teams to build on the framework both for us and their own projects. This promotes growth and could lead to more contributors, projects that use our code, and better visibility for things like donations. It's important to look at how features have been added in the past and how we should add them in the future. Most of my educational and professional experience has been with C# for concepts in OOP and C++ with regard to game engines or simulation. They are vastly different paradigms when it comes to writing code, and the luster of OOP begins to dissolve the closer you get to game dev. I think that as we start to decide between refactor and rewrite that we start looking at how things can be done and plan to implement them in a way that makes the transition possible to a fresh code base. This way we make progress even if a rewrite isn't possible. The important first question is, "Can we reasonably refactor?" I would not be opposed to another language, like .net (core). Since it is compiled into an intermediate language there are a lot of different things you can throw on top of it, including C++. It is also open source. I tend to look at newer languages with some cautious reluctance. This is not to say that new languages shouldn't be considered, but things like governance, licensing, and target should also be part of the decision making process. I see several job alerts for people with experience in Rust and Go, but I also recall the same skill requirement trend over Scala. I guess, I am saying that a balance should be struck between longevity of the language and ease of use for newcomers. I am open to learning a language that promotes these metrics. With regard to UI/UX, my impression based on the wealth of target platforms would be to consider using native platform look and feel. Unless we are attempting to make the product look better than what would be part of the system then we are losing the ability to provide an experience that appeals to users. @Kissaki brought up Xamarin which bridges that gap quite well. One of the benefits of the modular approach would be to give devs the option of a UI agnostic set of deliverables. As it is now, if we aren't bringing anything feature rich to Qt UI elements in terms of theming or customization then it may be more than we actually need. With their current requirements for obtaining the source becoming more intrusive it might be time to at least consider alternatives. I'm sure there are better network and translation libraries we could use. I have also seen some comments on product competition, including the addition of other features not part of the core set, such as video chat. I don't think we should discourage others who want to use the core framework to add in features like that. We should provide a way for them to plug in features if they choose to. I don't think Mumble should be more than what it is. I think it should do what it does better than other programs like it. Mumble was something I discovered because I didn't like TeamSpeak or Ventrillo, mostly because of user count restrictions. Discord is another failure of a perfectly good open source opportunity that I hoped Matrix would make up for. In some ways, it does. One of the biggest realizations I recently had during the meeting was the fact we don't use what we make as our main source of communication. It speaks volumes to the faith we have in what we are doing if we are using the product we make to collaborate on the product. I realize that Matrix is hosted by someone else, but maybe that is a consideration of where we could go with the project. I realize not all of this has to do with development of Mumble, but I think some of these concepts are worth putting out there for discussion as part of where we are trying to go with the project.

deekerman commented

Author

Owner

@streaps commented on GitHub (May 22, 2020):

My user (admin) experience with Mumble is that there are a lot of outdated Mumble libraries and that most libraries support only a subset of features. I'm talking about bots / moderation / RPC stuff written in all kinds of different languages (Python, Ruby, Lua, PHP, Go, Javascript, ...).

If there were one core library with bindings for other languages this could improve a lot of the ecosystem around mumble-voip/mumble. That was the main reason I mentioned Vala and C/GObject. There is also Gstreamer which implements most of the audio / dsp / codec (/ video) functionality that is used by Mumble.

@streaps commented on GitHub (May 22, 2020): My user (admin) experience with Mumble is that there are a lot of outdated Mumble libraries and that most libraries support only a subset of features. I'm talking about bots / moderation / RPC stuff written in all kinds of different languages (Python, Ruby, Lua, PHP, Go, Javascript, ...). If there were one core library with bindings for other languages this could improve a lot of the ecosystem around mumble-voip/mumble. That was the main reason I mentioned Vala and C/GObject. There is also Gstreamer which implements most of the audio / dsp / codec (/ video) functionality that is used by Mumble.

deekerman commented

Author

Owner

@jplatte commented on GitHub (May 22, 2020):

If you choose to port to Rust, you don't necessarily have to do that as a from-scratch rewrite. I haven't used it before, but the cxx crate should allow piece-by-piece translation of the code without too much overhead, and at the end things can be refactored to get a cleaner code base – refactoring IMHO is one of Rust's biggest strengths (due to its type system) in that it's totally feasible to refactor big parts of a codebase with no or very few new bugs.

Also, as a Mumble user / fan and a Rust dev with many years of experience, I'd be glad to help Mumble move to Rust through more general advice & design brainstorming should you need it, though I probably can't dedicate enough time to do much of the actual implementation.

@jplatte commented on GitHub (May 22, 2020): If you choose to port to Rust, you don't necessarily have to do that as a from-scratch rewrite. I haven't used it before, but the [cxx crate](https://github.com/dtolnay/cxx/) should allow piece-by-piece translation of the code without too much overhead, and at the end things can be refactored to get a cleaner code base – refactoring IMHO is one of Rust's biggest strengths (due to its type system) in that it's totally feasible to refactor big parts of a codebase with no or very few new bugs. Also, as a Mumble user / fan and a Rust dev with many years of experience, I'd be glad to help Mumble move to Rust through more general advice & design brainstorming should you need it, though I probably can't dedicate enough time to do much of the actual implementation.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 22, 2020):

Refactor vs. Rewrite

I think I have written it somewhere above already: In principle I agree that refactoring should b the way to go. In Mumble however I have kinda the feeling that a refactor of one component is more or less equal to starting a rewrite as there are so many cross-dependencies between code-areas.
And the probably biggest issue that I see is that a refactor doesn't really allow to change core designs in the code. As an example I would like to use the event system. Right now we're using Qt's signal and slot mechanism which works on a per-object-basis. This means that if I want to know when a user changes its name, I'll have to register my EventHandler (slot) to every single user object that currently exists and I'll also have to hook into the code that creates new user objects in order to not miss out on those.
The alternative I'd prefer would be a centralized EventSystem where all events go through an EventHub and on that all handlers are registered once and as all instances send their events to this hub, that single handler will receive all events of any object (even if that object doesn't exist at the point the handler is created yet).

I think it'd be really hard to start e.g. refactoring the audio code while using this new design when all other code still uses the old one...
Now that I write this though it occurs to me that the solution to this would probably be to first refactor the event system before refactoring other stuff 🤔

If you really want to rewrite it, at least I'd use a "tick tock approach".

@fedetft I assume by that you mean "rewrite a little part and once that's done integrate it into the current client"? If so then I think this could indeed be a good compromise between rewrite and refactor. I also think this is basically how I'd approached refactoring (more or less).

When it's ready, patch the old UI so that it calls the new core so you get people to use it and report bugs.

Good idea but for that to work we'd need a UI code that is not entangled with the backend. This however is sadly the case though :/

Programming Language

If backend is a Rust/Go and client frontend would be PyQt, it'll create new issues:

I was thinking that this would actually bring the great benefit that people that actually like designing UI stuff but don't like backend programming could then jump into the team as they could work with e.g. Python which is a lot less scary to most non-devs thatn c++/Rust/whatever. Therefore I was thinking this could be a big advantage of such a separation...

Thus as I see it the UI and the backend would be (basically) completely different projects with potentially completely different devs.

Therefore the debugging of the frontend should never involve debugging of the backend (and vice versa). If you find that the backend is behaving as it should, you report the bug to the backend devs and they'll look into it.

What about Vala and/or GObject C for the backend?

Never heard of these languages.

There are parts that mumble relies on that you definitely don't want to rewrite. The codecs, dsp stuff and GUI toolkit. These work well with C++, with other languages, not so much.

@fedetft you know the audio code way better than me by now, but I was always in the impression that the codec and DSP stuff was all handled by our 3rdparty libraries (which afaik are written in C and could thus be interfaced with from Rust). As for the GUI toolkit see the above reasoning. If we split frontend and backend, the GUI toolkit availability should not influence the choice of programming language for the backend.

Testing

One nitpick here: Mumble appears to have tests. I don't know how good the test suite is, but with good enough testing, you can mitigate this issue.

While this is true the tests that Mumble provides are not really worth mentioning here. The vast majority of the code is not covered by tests

Core library

If there were one core library with bindings for other languages this could improve a lot of the ecosystem around mumble-voip/mumble

I fully agree with that.

That was the main reason I mentioned Vala and C/GObject.

@streaps what do these languages have in common with the need for a core library? TO my knowledge everything that can expose the functionality iva C API should work 🤔

General

I'm worried however that may end up like with microservices — in Mumble case, monolith in C++ seems to be better.

@Reikion where do you see the potential for microservices here? I think I don't quite understand the point you're trying to make here 🤔

I basically agree with everything @ZeroAbility wrote. We should modularize the code and make it as easy as possible for others to use the base code and extend it to their needs (add new / specific features on top of it, build a new UI, etc).
Using native UI was also something I was thinking about but I guess this would only be feasible if we found enough helping hands for each OS we want to support...

@Krzmbrzl commented on GitHub (May 22, 2020): # Refactor vs. Rewrite I think I have written it somewhere above already: In principle I agree that refactoring should b the way to go. In Mumble however I have kinda the feeling that a refactor of one component is more or less equal to starting a rewrite as there are so many cross-dependencies between code-areas. And the probably biggest issue that I see is that a refactor doesn't really allow to change core designs in the code. As an example I would like to use the event system. Right now we're using Qt's signal and slot mechanism which works on a per-object-basis. This means that if I want to know when a user changes its name, I'll have to register my EventHandler (slot) to every single user object that currently exists and I'll also have to hook into the code that creates new user objects in order to not miss out on those. The alternative I'd prefer would be a centralized EventSystem where all events go through an EventHub and on that all handlers are registered once and as all instances send their events to this hub, that single handler will receive all events of any object (even if that object doesn't exist at the point the handler is created yet). I think it'd be really hard to start e.g. refactoring the audio code while using this new design when all other code still uses the old one... Now that I write this though it occurs to me that the solution to this would probably be to first refactor the event system before refactoring other stuff :thinking: > If you really want to rewrite it, at least I'd use a "tick tock approach". @fedetft I assume by that you mean "rewrite a little part and once that's done integrate it into the current client"? If so then I think this could indeed be a good compromise between rewrite and refactor. I also think this is basically how I'd approached refactoring (more or less). > When it's ready, patch the old UI so that it calls the new core so you get people to use it and report bugs. Good idea but for that to work we'd need a UI code that is not entangled with the backend. This however is sadly the case though :/ # Programming Language > If backend is a Rust/Go and client frontend would be PyQt, it'll create new issues: I was thinking that this would actually bring the great benefit that people that actually like designing UI stuff but don't like backend programming could then jump into the team as they could work with e.g. Python which is a lot less scary to most non-devs thatn c++/Rust/whatever. Therefore I was thinking this could be a big advantage of such a separation... Thus as I see it the UI and the backend would be (basically) completely different projects with potentially completely different devs. Therefore the debugging of the frontend should never involve debugging of the backend (and vice versa). If you find that the backend is behaving as it should, you report the bug to the backend devs and they'll look into it. > What about Vala and/or GObject C for the backend? Never heard of these languages. > There are parts that mumble relies on that you definitely don't want to rewrite. The codecs, dsp stuff and GUI toolkit. These work well with C++, with other languages, not so much. @fedetft you know the audio code way better than me by now, but I was always in the impression that the codec and DSP stuff was all handled by our 3rdparty libraries (which afaik are written in C and could thus be interfaced with from Rust). As for the GUI toolkit see the above reasoning. If we split frontend and backend, the GUI toolkit availability should not influence the choice of programming language for the backend. # Testing > One nitpick here: Mumble appears to have tests. I don't know how good the test suite is, but with good enough testing, you can mitigate this issue. While this is true the tests that Mumble provides are not really worth mentioning here. The vast majority of the code is not covered by tests # Core library > If there were one core library with bindings for other languages this could improve a lot of the ecosystem around mumble-voip/mumble I fully agree with that. > That was the main reason I mentioned Vala and C/GObject. @streaps what do these languages have in common with the need for a core library? TO my knowledge everything that can expose the functionality iva C API should work :thinking: # General > I'm worried however that may end up like with microservices — in Mumble case, monolith in C++ seems to be better. @Reikion where do you see the potential for microservices here? I think I don't quite understand the point you're trying to make here :thinking: I basically agree with everything @ZeroAbility wrote. We should modularize the code and make it as easy as possible for others to use the base code and extend it to their needs (add new / specific features on top of it, build a new UI, etc). Using native UI was also something I was thinking about but I guess this would only be feasible if we found enough helping hands for each OS we want to support...

deekerman commented

Author

Owner

@jplatte commented on GitHub (May 22, 2020):

I was thinking that this would actually bring the great benefit that people that actually like designing UI stuff but don't like backend programming could then jump into the team as they could work with e.g. Python which is a lot less scary to most non-devs thatn c++/Rust/whatever. Therefore I was thinking this could be a big advantage of such a separation...

My 2c:

Don't do plans based on potential new devs appearing. Scratch your own itch first. The people who are involved in the porting / rewriting / refactoring / whatever should be the ones selecting languages / tools / libraries to work with, based on what makes them come back to the huge pile of work it's going to be.

If you have selected Go and Rust as candidates for a rewrite because you've heard good things about them, but don't have much personal experience, take some time to gain that experience first and decide based on that.

And if you decide to go for Rust audio processing / backend + Python UI, PyO3 might¹ be useful for exposing the backend to the UI².

¹ purely based on me having heard of it and the project looking active and healthy
² should you want "direct" interop at all, rather than splitting backend and frontend into separate processes

@jplatte commented on GitHub (May 22, 2020): > I was thinking that this would actually bring the great benefit that people that actually like designing UI stuff but don't like backend programming could then jump into the team as they could work with e.g. Python which is a lot less scary to most non-devs thatn c++/Rust/whatever. Therefore I was thinking this could be a big advantage of such a separation... My 2c: Don't do plans based on potential new devs appearing. Scratch your own itch first. The people who are involved in the porting / rewriting / refactoring / whatever should be the ones selecting languages / tools / libraries to work with, based on what makes them come back to the huge pile of work it's going to be. If you have selected Go and Rust as candidates for a rewrite because you've heard good things about them, but don't have much personal experience, take some time to gain that experience first and decide based on that. And if you decide to go for Rust audio processing / backend + Python UI, [PyO3](https://pyo3.rs/v0.10.1/) might¹ be useful for exposing the backend to the UI². ¹ purely based on me having heard of it and the project looking active and healthy ² should you want "direct" interop at all, rather than splitting backend and frontend into separate processes

deekerman commented

Author

Owner

@ghost commented on GitHub (May 22, 2020):

@Krzmbrzl: Using native UI was also something I was thinking about but I guess this would only be feasible if we found enough helping hands for each OS we want to support...

Not necessarily. Xamarin was brought up and there is also .net MAUI. I'm sure there are several other native UI toolkits that are multi-platform that could be considered. I agree that we shouldn't be tethering things like events to the UI for the same reason as the speex and celt example. Qt could decide one day to leave the OSS community out in the cold as they leverage their commercial product which could leave significant parts of the project in limbo. Technology moves so fast that it only makes sense to look at each part of the whole and plan for the possibility that a better solution may come along or the existing one may go away.

@ghost commented on GitHub (May 22, 2020): > @Krzmbrzl: Using native UI was also something I was thinking about but I guess this would only be feasible if we found enough helping hands for each OS we want to support... Not necessarily. Xamarin was brought up and there is also [.net MAUI](https://github.com/dotnet/maui). I'm sure there are several other native UI toolkits that are multi-platform that could be considered. I agree that we shouldn't be tethering things like events to the UI for the same reason as the speex and celt example. Qt could decide one day to leave the OSS community out in the cold as they leverage their commercial product which could leave significant parts of the project in limbo. Technology moves so fast that it only makes sense to look at each part of the whole and plan for the possibility that a better solution may come along or the existing one may go away.

deekerman commented

Author

Owner

@ghost commented on GitHub (May 22, 2020):

@streaps: My user (admin) experience with Mumble is that there are a lot of outdated Mumble libraries and that most libraries support only a subset of features. I'm talking about bots / moderation / RPC stuff written in all kinds of different languages (Python, Ruby, Lua, PHP, Go, Javascript, ...).
If there were one core library with bindings for other languages this could improve a lot of the ecosystem around mumble-voip/mumble.

@streaps OTOH we are going to end up with bunch of incomplete, outdated bindings, which can't be automatically generated via .proto like specification. And one part is client side bindings, the other one server side bindings.

@Reikion where do you see the potential for microservices here? I think I don't quite understand the point you're trying to make here thinking

@Krzmbrzl I can't see any potential for microservices. I thought about trend in general to split stuff too much for nearly no gain. I might be wrong though.

@ghost commented on GitHub (May 22, 2020): > @streaps: My user (admin) experience with Mumble is that there are a lot of outdated Mumble libraries and that most libraries support only a subset of features. I'm talking about bots / moderation / RPC stuff written in all kinds of different languages (Python, Ruby, Lua, PHP, Go, Javascript, ...). > If there were one core library with bindings for other languages this could improve a lot of the ecosystem around mumble-voip/mumble. @streaps OTOH we are going to end up with bunch of incomplete, outdated bindings, which can't be automatically generated via .proto like specification. And one part is client side bindings, the other one server side bindings. > @Reikion where do you see the potential for microservices here? I think I don't quite understand the point you're trying to make here thinking @Krzmbrzl I can't see any potential for microservices. I thought about trend in general to split stuff too much for nearly no gain. I might be wrong though.

deekerman commented

https://en.wikipedia.org/wiki/PyGTK#PyGObject
https://en.wikipedia.org/wiki/GObject

Author

Owner

@streaps commented on GitHub (May 22, 2020):

OTOH we are going to end up with bunch of incomplete, outdated bindings, which can't be automatically generated via .proto like specification. And one part is client side bindings, the other one server side bindings.

Not sure what you are talking about

@streaps commented on GitHub (May 22, 2020): > OTOH we are going to end up with bunch of incomplete, outdated bindings, which can't be automatically generated via .proto like specification. And one part is client side bindings, the other one server side bindings. Not sure what you are talking about https://en.wikipedia.org/wiki/PyGTK#PyGObject https://en.wikipedia.org/wiki/GObject

deekerman commented

Author

Owner

@ghost commented on GitHub (May 22, 2020):

Ok, my bad. But still, imo C with GObject is step backward.

@ghost commented on GitHub (May 22, 2020): Ok, my bad. But still, imo C with GObject is step backward.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 23, 2020):

we are going to end up with bunch of incomplete, outdated bindings

Well the interface can't really be outdated if the main client is dependent on those as well. And I think having a 3rdParty library have outdated bindings (e.g. no bindings for the newest stuff) is probably better than having outdated functionality (that might even be broken) in it 🤷

I thought about trend in general to split stuff too much for nearly no gain. I might be wrong though.

Well we should of course not exaggerate. But the separation that has been suggested so far (frontend / backend in the client and potentially CLI / backend in the server) all have good reasons for existence (imo at least) and overall shouldn't be too much overhead in creating/maintaining.

@Krzmbrzl commented on GitHub (May 23, 2020): > we are going to end up with bunch of incomplete, outdated bindings Well the interface can't really be outdated if the main client is dependent on those as well. And I think having a 3rdParty library have outdated bindings (e.g. no bindings for the newest stuff) is probably better than having outdated functionality (that might even be broken) in it :shrug: > I thought about trend in general to split stuff too much for nearly no gain. I might be wrong though. Well we should of course not exaggerate. But the separation that has been suggested so far (frontend / backend in the client and potentially CLI / backend in the server) all have good reasons for existence (imo at least) and overall shouldn't be too much overhead in creating/maintaining.

deekerman commented

Author

Owner

@streaps commented on GitHub (May 23, 2020):

But still, imo C with GObject is step backward.

But then there is also Vala, which is a more high-level GObject-based language (compiles to C). I don't know if this would be a better choice than C++, Rust or another language. I just wanted to mention it.

I did some minor modifications in Gajim (reordered the voice codec priorities and enabled Opus)., which uses Farstream (Gstreamer-based) with the help of PyGObject. Gstreamer is really powerful and it has maybe 90% of all the building blocks for Mumble's audio/video streaming and I/O requirements – cross-platform. Being able to use it from many languages is very useful.

@streaps commented on GitHub (May 23, 2020): > But still, imo C with GObject is step backward. But then there is also Vala, which is a more high-level GObject-based language (compiles to C). I don't know if this would be a better choice than C++, Rust or another language. I just wanted to mention it. I did some minor modifications in Gajim (reordered the voice codec priorities and enabled Opus)., which uses Farstream (Gstreamer-based) with the help of PyGObject. Gstreamer is really powerful and it has maybe 90% of all the building blocks for Mumble's audio/video streaming and I/O requirements – cross-platform. Being able to use it from many languages is very useful.

deekerman commented

Author

Owner

@jplatte commented on GitHub (May 23, 2020):

Vala is on the way out. It's not really maintained, and lots of GNOME developers (Vala is part of pretty much part of GNOME) are moving to Rust as to go-to higherlevel language instead.

@jplatte commented on GitHub (May 23, 2020): Vala is on the way out. It's not really maintained, and lots of GNOME developers (Vala is part of pretty much part of GNOME) are moving to Rust as to go-to higherlevel language instead.

deekerman commented

Author

Owner

@streaps commented on GitHub (May 23, 2020):

Vala is on the way out. It's not really maintained, ...

A urban myth not supported by data.

and lots of GNOME developers (Vala is part of pretty much part of GNOME) are moving to Rust as to go-to higherlevel language instead.

and when will Rust be on the way out? ;)

@streaps commented on GitHub (May 23, 2020): > Vala is on the way out. It's not really maintained, ... A urban myth not supported by data. > and lots of GNOME developers (Vala is part of pretty much part of GNOME) are moving to Rust as to go-to higherlevel language instead. and when will Rust be on the way out? ;)

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 23, 2020):

Vala is on the way out. It's not really maintained,

The elementaryOS people have used Vala to write basically all of their apps. The app center of the OS is also full of Vala-made apps, and the OS developers have pushed a lot of patches to the GNOME toolkits over the years. It's definitely being maintained and used, as far as I can tell :)

@felix91gr commented on GitHub (May 23, 2020): > Vala is on the way out. It's not really maintained, The elementaryOS people have used Vala to write basically all of their apps. The app center of the OS is also full of Vala-made apps, and the OS developers have pushed a lot of patches to the GNOME toolkits over the years. It's definitely being maintained and used, as far as I can tell :)

deekerman commented

Author

Owner

@jplatte commented on GitHub (May 23, 2020):

Oh okay, sorry for the wrong info. I thought I'd heard from a GNOME dev that nobody is really working on it anymore (and many users are using away from it). I've hidden my previous comment.

@jplatte commented on GitHub (May 23, 2020): Oh okay, sorry for the wrong info. I thought I'd heard from a GNOME dev that nobody is really working on it anymore (and many users are using away from it). I've hidden my previous comment.

deekerman commented

Author

Owner

@theAkito commented on GitHub (May 23, 2020):

I think most of the important stuff is already mentioned, so I do not have much to add. Though, I'd still like to insert my 2 cents into the conversation, if I may. 😃

I am against keeping it in C/C++, because alternatives, like e.g. Rust, are plain better. Just objectively plain better. Rust is safe, Rust is fresh, Rust is the future, being already available and stable. You can write just as fast and good code with Rust, as you can with C/C++.
So my vote definitely falls on Rust.

@theAkito commented on GitHub (May 23, 2020): I think most of the important stuff is already mentioned, so I do not have much to add. Though, I'd still like to insert my 2 cents into the conversation, if I may. 😃 I am against keeping it in C/C++, because alternatives, like e.g. Rust, are plain better. Just objectively plain better. Rust is safe, Rust is fresh, Rust is the future, being already available and stable. You can write just as fast and good code with Rust, as you can with C/C++. So my vote definitely falls on Rust.

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 24, 2020):

I am against keeping it in C/C++, because alternatives, like e.g. Rust, are plain better. Just objectively plain better. Rust is safe, Rust is fresh, Rust is the future, being already available and stable. You can write just as fast and good code with Rust, as you can with C/C++.

What you decide on to be better entirely depends on what you value to what degrees. Technical, theoretical superiority is not the only measure that has to be applied. Blind hype is dangerous. Just because it is or feels "fresh" as you say, which is an entirely soft, superficial and subjective measurement does not make it better at all.

We are looking at a productive discussion here. And we would do good to try and keep it honest and on point.

A decision for a superior technology with nobody to maintain it is worse than an inferior technology with people to maintain it.

@Kissaki commented on GitHub (May 24, 2020): > I am against keeping it in C/C++, because alternatives, like e.g. Rust, are plain better. Just objectively plain better. Rust is safe, Rust is fresh, Rust is the future, being already available and stable. You can write just as fast and good code with Rust, as you can with C/C++. What you decide on to be better entirely depends on what you value to what degrees. Technical, theoretical superiority is not the only measure that has to be applied. Blind hype is dangerous. Just because it is or feels "fresh" as you say, which is an entirely soft, superficial and subjective measurement does not make it better at all. We are looking at a productive discussion here. And we would do good to try and keep it honest and on point. A decision for a superior technology with nobody to maintain it is worse than an inferior technology with people to maintain it.

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 24, 2020):

You're right, @Kissaki.
I'm on a phone and it's ungodly late, but I'll do my best to bring you proof that Rust is here to stay, and that it has a lot of support.

Exhibit A: Microsoft

We believe Rust changes the game when it comes to writing safe systems software. Rust provides the performance and control needed to write low-level systems, while empowering software developers to write robust, secure programs.

(MS Security Response Center)

Microsoft has expressed more and more appreciation for Rust lately. Here's a couple of things they've written and are making regarding Rust:

They've expressed that they consider Rust to be the option for the future of their systems programming projects
Last week or so, Windows just announced their new Rust/WinRT project, to bring direct Windows Runtime support for Rust.
Microsoft Azure has sponsored CI machines to run the pipelines that the compiler project uses in a day to day basis.

Exhibit B: Google

I'm not as up-to-date with Google as I am with MS. But here's what I know about what Google is doing with Rust:

Their Fuschia project is based on Rust.
The've been keeping up-to-date TensorFlow bindings to Rust.
They've just given Google Cloud machines for free to run Crater on them. This is a really, really intensive pipeline that's used to look for regressions across the entire Rust ecosystem, by testing how the compiler behaves with more or less every library under the canonical index of libs (crates.io).

Posts or names of users of Rust in production

Discord is switching from Go to Rust, after a really enlightening experience with the performance limits of Go.
Dropbox has rewritten their sync engine in Rust
The NPM (Node Package Manager) team picked Rust over Go for their CPU-bound bottlenecks

More names

Here's a list of users of Rust in production: https://www.rust-lang.org/production/users

I hope this was more or less illustrative. Imma sleep now. Let me know if you need more links Kissaki. I'm happy to bring them ☺️

... 🥱
Have a great day/night!

@felix91gr commented on GitHub (May 24, 2020): You're right, @Kissaki. I'm on a phone and it's ungodly late, but I'll do my best to bring you proof that Rust is here to stay, and that it has a lot of support. #### Exhibit A: Microsoft > We believe Rust changes the game when it comes to writing safe systems software. Rust provides the performance and control needed to write low-level systems, while empowering software developers to write robust, secure programs. _(MS Security Response Center)_ Microsoft has expressed more and more appreciation for Rust lately. Here's a couple of things they've written and are making regarding Rust: * They've expressed that they consider Rust to be [_the_ option for the future of their systems programming projects](https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/) * Last week or so, Windows just announced their new [Rust/WinRT](https://github.com/microsoft/winrt-rs) project, to bring direct Windows Runtime support for Rust. * Microsoft Azure has sponsored CI machines to run the pipelines that the compiler project uses in a day to day basis. #### Exhibit B: Google I'm not as up-to-date with Google as I am with MS. But here's what I know about what Google is doing with Rust: * Their Fuschia project is based on Rust. * The've been keeping up-to-date [TensorFlow bindings](https://github.com/tensorflow/rust ) to Rust. * They've just given Google Cloud machines for free to run Crater on them. This is a really, really intensive pipeline that's used to look for regressions across the entire Rust ecosystem, by testing how the compiler behaves with more or less every library under the canonical index of libs (crates.io). #### Posts or names of users of Rust in production * Discord is [switching from Go to Rust](https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f?gi=d00f1241938c), after a really enlightening experience with the performance limits of Go. * Dropbox has [rewritten their **sync engine** in Rust](https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine) * The NPM (Node Package Manager) team [picked Rust over Go for their CPU-bound bottlenecks](https://www.rust-lang.org/static/pdfs/Rust-npm-Whitepaper.pdf) #### More names Here's a list of users of Rust in production: https://www.rust-lang.org/production/users --- I hope this was more or less illustrative. Imma sleep now. Let me know if you need more links Kissaki. I'm happy to bring them ☺️ ... 🥱 Have a great day/night!

deekerman commented

Author

Owner

@theAkito commented on GitHub (May 24, 2020):

@Kissaki

If everyone just keeps thw most maintainable and the most known stuff in open repositories, we would still be sitting here with punch cards and type writers, writing our code.

Change is not easy. That does not mean that change is per sé bad or unnecessary.

The "fresh" part was just a summary of the language's stage. It was also one of the minor points. The safety of Rust is actually the biggest point I always have in mind, when thinking of or talking about this language. The "freshness" itself doesn't really matter, so it was a bit unfair to display it like it would be my main point.

That said, the need for a safe program is neither superficial, nor subjective. It is always important if you want to have a production ready system. So that is one of the huge reasons, why Rust is plain better.
This change in the world needs to happen and it would be one of many good starting points if it were implemented here, in this project, already as well.

Despite you taking parts of my comment out of context, it still ironically seems like you agree that Rust is better, at least that's what I interpret from your reply.
If it is better, then let's take the better way instead of sitting here with ALGOL or FORTRAN just because I know some excellent programmers that are proficient in those languages for decades...

C, etc. is outdated. It doesn't live up to today's possibilities and wastes a lot of Dev time just because it is an unintelligent language. The only reason why C is so famous and used all ovet the place, is because at the time, back then this was the best you could get. However, that was 30 years ago. Now, there are languages, like Rust, that are just better.

I know, you can't make friends with the following, but you wanted honesty and here is what I honestly think:
If someone is proficient in C/C++ and they want to keep the source in this spectrum just because it's familiar, I highly recommend switching entirely to Rust in general and dropping C for good, as the latter should be erased from today's projects, anyway...

@theAkito commented on GitHub (May 24, 2020): @Kissaki If everyone just keeps thw most maintainable and the most known stuff in open repositories, we would still be sitting here with punch cards and type writers, writing our code. Change is not easy. That does not mean that change is per sé bad or unnecessary. The "fresh" part was just a summary of the language's stage. It was also one of the minor points. The safety of Rust is actually the biggest point I always have in mind, when thinking of or talking about this language. The "freshness" itself doesn't really matter, so it was a bit unfair to display it like it would be my main point. That said, the need for a safe program is neither superficial, nor subjective. It is always important if you want to have a production ready system. So that is one of the huge reasons, why Rust is plain better. This change in the world needs to happen and it would be one of many good starting points if it were implemented here, in this project, already as well. Despite you taking parts of my comment out of context, it still ironically seems like you agree that Rust is better, at least that's what I interpret from your reply. If it *is* better, then let's take the better way instead of sitting here with ALGOL or FORTRAN just because I know some excellent programmers that are proficient in those languages for decades... C, etc. is outdated. It doesn't live up to today's possibilities and wastes a lot of Dev time just because it is an unintelligent language. The only reason why C is so famous and used all ovet the place, is because *at the time, back then* this was the best you could get. However, that was 30 years ago. Now, there are languages, like Rust, that are just better. I know, you can't make friends with the following, but you wanted honesty and here is what I honestly think: If someone is proficient in C/C++ and they want to keep the source in this spectrum just because it's familiar, I highly recommend switching entirely to Rust in general and dropping C for good, as the latter should be erased from today's projects, anyway...

deekerman commented

https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_processing/include/audio_processing.h

Author

Owner

@fedetft commented on GitHub (May 24, 2020):

Not to insist, but it looks like the pro-rust team is missing an important point: how are you going to make the GUI? Mumble is not a web service with which people interact through a web browser (thankfully!).

Moreover, if we choose modern C++ we get the possibility to refactor things a bit at a time and get users to benefit from our efforts right now, instead of at an unknown date when the rewrite is finally good enough.

And finally, if there's no audio programmers in the Mumble team and we want to switch to a ready made solution such as webrtc's audio processor, that's C++, and it isn't that easy to call from rust.

@fedetft commented on GitHub (May 24, 2020): Not to insist, but it looks like the pro-rust team is missing an important point: how are you going to make the GUI? Mumble is not a web service with which people interact through a web browser (thankfully!). Moreover, if we choose modern C++ we get the possibility to refactor things a bit at a time and get users to benefit from our efforts right now, instead of at an unknown date when the rewrite is finally good enough. And finally, if there's no audio programmers in the Mumble team and we want to switch to a ready made solution such as webrtc's audio processor, that's C++, and it isn't that easy to call from rust. https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_processing/include/audio_processing.h

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 24, 2020):

how are you going to make the GUI?

As stated before: GUI is not an issue. The GUI would be separate anyways and potentially even in another programming language.

@Krzmbrzl commented on GitHub (May 24, 2020): > how are you going to make the GUI? As stated before: GUI is not an issue. The GUI would be separate anyways and potentially even in another programming language.

deekerman commented

Author

Owner

@jairomer commented on GitHub (May 24, 2020):

Hi,

First of all, thank you for the project. My country is in lockdown and I was able to have a chat with my dispersed family using this software with little issues apart from echo during the call from time to time, which seems a very interesting and challenging problem to solve.

Regarding the rewrite, and after checking out the code of the project, it trully looks like it was written by a C person which could use some namespaces here and there, use CMake as the build system, write the requirements of each part of the code into functional tests (https://github.com/google/googletest) and maybe update to C++17. However, as ugly as it looks, it has a lot of work invested in and most importantly, it works.

I have observed an intense focus on this thread onto which programming language to use, but if the objective is to improve the maintenability of the code, the answer lies in less sexy tasks like having a good project architecture and tests to verify that the addition of new functionalities or code updates does not harm its behaviour or introduces new bugs. Simple and boring but reliable software engineering which can be done C++ while reusing all the hard work involved in the codebase. However, if the kernel of the project could be used as a dynamic or static library, it could be potentially used with any kind of front end in any language.

Just my opinion :), if a C++ rewrite or refactor is made in the end, I could give a helping hand.

@jairomer commented on GitHub (May 24, 2020): Hi, First of all, thank you for the project. My country is in lockdown and I was able to have a chat with my dispersed family using this software with little issues apart from echo during the call from time to time, which seems a very interesting and challenging problem to solve. Regarding the rewrite, and after checking out the code of the project, it trully looks like it was written by a C person which could use some namespaces here and there, use CMake as the build system, write the requirements of each part of the code into functional tests (https://github.com/google/googletest) and maybe update to C++17. However, as ugly as it looks, it has a lot of work invested in and most importantly, it works. I have observed an intense focus on this thread onto which programming language to use, but if the objective is to improve the maintenability of the code, the answer lies in less sexy tasks like having a good project architecture and tests to verify that the addition of new functionalities or code updates does not harm its behaviour or introduces new bugs. Simple and boring but reliable software engineering which can be done C++ while reusing all the hard work involved in the codebase. However, if the kernel of the project could be used as a dynamic or static library, it could be potentially used with any kind of front end in any language. Just my opinion :), if a C++ rewrite or refactor is made in the end, I could give a helping hand.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 25, 2020):

A cmake port is already in the making (and close to being finished) by @davidebeatrici and @ZeroAbility.

but if the objective is to improve the maintenability of the code, the answer lies in less sexy tasks like having a good project architecture and tests to verify that the addition of new functionalities or code updates does not harm its behaviour or introduces new bugs.

Absolutely right. I was simply thinking that if at all, this would be the time to switch to a new language, which is why I wanted to explore the possibilities and get some ideas/feedback on the idea :)

@Krzmbrzl commented on GitHub (May 25, 2020): A cmake port is already in the making (and close to being finished) by @davidebeatrici and @ZeroAbility. > but if the objective is to improve the maintenability of the code, the answer lies in less sexy tasks like having a good project architecture and tests to verify that the addition of new functionalities or code updates does not harm its behaviour or introduces new bugs. Absolutely right. I was simply thinking that if at all, this would be the time to switch to a new language, which is why I wanted to explore the possibilities and get some ideas/feedback on the idea :)

deekerman commented

Author

Owner

@streaps commented on GitHub (May 25, 2020):

Just an idea (without knowing much about the C++/Qt code):

what about starting with a mumble-core-audio library that could be used by the Mumble Qt client and/or a future new client?

Maybe this could even be run as a separate process / daemon even on another machine and controlled over some RPC.

@streaps commented on GitHub (May 25, 2020): Just an idea (without knowing much about the C++/Qt code): what about starting with a mumble-core-audio library that could be used by the Mumble Qt client and/or a future new client? Maybe this could even be run as a separate process / daemon even on another machine and controlled over some RPC.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 25, 2020):

This kind of separation is pretty much what is planned (referred to as "frontend/backend separation") ;)

@Krzmbrzl commented on GitHub (May 25, 2020): This kind of separation is pretty much what is planned (referred to as "frontend/backend separation") ;)

deekerman commented

Author

Owner

@bendem commented on GitHub (May 25, 2020):

I would tend to agree with @jairomer. The problem, in my opinion, with mumble is an architectural one that can be just as easily solved in C++ than in any other language. There is a lot of work that has been done on fixing edge cases and handling different platform consistently that would be lost by starting again from scratch.

Specifying, documenting the contract between the client and the server (beyond what is technically encoded in the proto files) is the hard part.

Maybe instead of replacing the actual Qt/C++ implementation, we could have a spec and multiple implementations (a go and a python client could speak with a rust server, administered with a .Net GUI and a C++ CLI).

I'd like to see a task force work on that (standardization) instead of delaying the next update by another 5 years (remember when we said, never again such a long time between releases?) until we reach feature parity of the rewrite with what already exists.

I'm in no way against someone starting a rewrite from scratch but I don't see why this has to be formally done as a replacement of the current software instead of in addition to its ecosystem.

@bendem commented on GitHub (May 25, 2020): I would tend to agree with @jairomer. The problem, in my opinion, with mumble is an architectural one that can be just as easily solved in C++ than in any other language. There is a lot of work that has been done on fixing edge cases and handling different platform consistently that would be lost by starting again from scratch. Specifying, documenting the contract between the client and the server (beyond what is technically encoded in the proto files) is the hard part. Maybe instead of replacing the actual Qt/C++ implementation, we could have a spec and multiple implementations (a go and a python client could speak with a rust server, administered with a .Net GUI and a C++ CLI). I'd like to see a task force work on that (standardization) instead of delaying the next update by another 5 years (remember when we said, never again such a long time between releases?) until we reach feature parity of the rewrite with what already exists. I'm in no way against someone starting a rewrite from scratch but I don't see why this has to be formally done as a replacement of the current software instead of in addition to its ecosystem.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 25, 2020):

Just something I'd like to mention here in regards to the argument that the current code does handle edge case and already encountered bugs: This is obviously true but as the vast majority of this handling is undocumented, it's really hard to determine what is a valid fix and what is simply odd coding. This is the kind of thing that would massively complicate a refactoring in my eyes as you either have to overtake every quirk the code currently has (in which case you can just leave it as it is) or you have to spend probably massive amounts of time figuring out what that weird line of code is for and if it is vital for something (which then would delay any ongoing work on other stuff as the devs are busy understanding old code).

This is of course not an argument that clearly shows a rewrite is better or anything, but I did want to bring this issue up here ☝️

Maybe instead of replacing the actual Qt/C++ implementation, we could have a spec and multiple implementations (a go and a python client could speak with a rust server, administered with a .Net GUI and a C++ CLI).

This would of course be nice but that'd either slow down future development quite a bit (as every addition to the standard needs discussion with basically all parties that implement a piece of software based on that standard) and most importantly: it'll lead to (probably a lot of) outdated Mumble implementations.
If we instead have one core library every other program in the echo system can use as its basis and which is maintained and updated centrally, there's much less potential of having outdated implementations laying around and also less potential for devs misinterpreting "the standard" leading to buggy edge case in various applications.

why this has to be formally done as a replacement of the current software instead of in addition to its ecosystem.

Probably because working with the current code base isn't that fun once you need to dig in deeper and thus I guess the active devs have the most reasons and motivation to start the rewrite :P

@Krzmbrzl commented on GitHub (May 25, 2020): Just something I'd like to mention here in regards to the argument that the current code does handle edge case and already encountered bugs: This is obviously true but as the vast majority of this handling is undocumented, it's really hard to determine what is a valid fix and what is simply odd coding. This is the kind of thing that would massively complicate a refactoring in my eyes as you either have to overtake every quirk the code currently has (in which case you can just leave it as it is) or you have to spend probably massive amounts of time figuring out what that weird line of code is for and if it is vital for something (which then would delay any ongoing work on other stuff as the devs are busy understanding old code). This is of course not an argument that clearly shows a rewrite is better or anything, but I did want to bring this issue up here :point_up: > Maybe instead of replacing the actual Qt/C++ implementation, we could have a spec and multiple implementations (a go and a python client could speak with a rust server, administered with a .Net GUI and a C++ CLI). This would of course be nice but that'd either slow down future development quite a bit (as every addition to the standard needs discussion with basically all parties that implement a piece of software based on that standard) and most importantly: it'll lead to (probably a lot of) outdated Mumble implementations. If we instead have one core library every other program in the echo system can use as its basis and which is maintained and updated centrally, there's much less potential of having outdated implementations laying around and also less potential for devs misinterpreting "the standard" leading to buggy edge case in various applications. > why this has to be formally done as a replacement of the current software instead of in addition to its ecosystem. Probably because working with the current code base isn't that fun once you need to dig in deeper and thus I guess the active devs have the most reasons and motivation to start the rewrite :P

deekerman commented

Author

Owner

@bendem commented on GitHub (May 25, 2020):

This would of course be nice but that'd either slow down future development quite a bit (as every addition to the standard needs discussion with basically all parties that implement a piece of software based on that standard) and most importantly: it'll lead to (probably a lot of) outdated Mumble implementations.

Existing software shows this is not true if the protocol is thought about in both core and extensions (think IRC, XMPP, AMQP). Clients can be largely simplified with this by only implementing the parts they are interested in (bots could completely skip audio, some clients could skip PA or chat, encryption and OTR could be developed independently from core, video could be optionally added). This way, implementors only maintain the part they are actually using and are less likely to abandon their software due to an unrelated breaking change they can't fix.

This of course makes the server slightly more complex by requiring it to handle clients with different capabilities, but that light cost is vastly paid by the diversity of simpler clients that could emerge.

@bendem commented on GitHub (May 25, 2020): > This would of course be nice but that'd either slow down future development quite a bit (as every addition to the standard needs discussion with basically all parties that implement a piece of software based on that standard) and most importantly: it'll lead to (probably a lot of) outdated Mumble implementations. Existing software shows this is not true if the protocol is thought about in both core and extensions (think IRC, XMPP, AMQP). Clients can be largely simplified with this by only implementing the parts they are interested in (bots could completely skip audio, some clients could skip PA or chat, encryption and OTR could be developed independently from core, video could be optionally added). This way, implementors only maintain the part they are actually using and are less likely to abandon their software due to an unrelated breaking change they can't fix. This of course makes the server slightly more complex by requiring it to handle clients with different capabilities, but that light cost is vastly paid by the diversity of simpler clients that could emerge.

deekerman commented

Author

Owner

@streaps commented on GitHub (May 25, 2020):

I think especially XMPP is a good example why a ton of different implementations and libs is just a unmaintainable mess. The XEP for jingle audio was released 15 years ago. There were several attempts to implement voice calls, most failed miserably.

How many Mumble client libraries are there? How many of them have support for:

UDP voice
sound card I/O
echo cancel
noise suppression
VAD
AGC
UDP to TCP fallback and UDP reconnect
...

How many support all of these features, which are more or less essential for a voice chat client in 2020?

@streaps commented on GitHub (May 25, 2020): I think especially XMPP is a good example why a ton of different implementations and libs is just a unmaintainable mess. The XEP for jingle audio was released 15 years ago. There were several attempts to implement voice calls, most failed miserably. How many Mumble client libraries are there? How many of them have support for: - UDP voice - sound card I/O - echo cancel - noise suppression - VAD - AGC - UDP to TCP fallback and UDP reconnect - ... How many support all of these features, which are more or less essential for a voice chat client in 2020?

deekerman commented

Author

Owner

@vimpostor commented on GitHub (May 25, 2020):

OK, so I will keep this short as most stuff has already been said, but you can't stress this enough:

I couldn't agree more with @Reikion, in fact I was going to post the same article.

Particularly, I would like to highlight this paragraph:

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

In short, it would be absolutely stupid to rewrite Mumble from scratch. Refactoring a code base to look nicer is absolutely always easier than rewriting it.

I understand that Rust offers nice modern language features, but so does a recent C++ standard.

From the few parts of Mumble that I have personally touched, I can see how the Mumble codebase is an utterly convoluted piece of dumbster fire.

But, it is easier to refactor than rewrite Mumble, thus I would like to see the following:

Start using modern C++
The code still uses C style memory management with new and delete, use smart pointers instead
It is fair to require C++17 in 2020
There is no need to support very old Ubuntu LTS distros natively, their shipped library versions will hold back a modern codebase. Those distros can still be supported via other means like Appimage.
Start porting to Qt 6 as soon as possible, Mumble used Qt 4 for way too long
Some custom platform-specific code in Mumble can be ported to Qt API entirely, removing our own platform specific implementation
Generally, this codebase reeks of old stuff. I think it would be perfectly fine to only support the modern Opus codec for example.
Imho inheritance based OOP should be removed and be replaced with functional style interface-implementation based "OOP" like Rust or Haskell (though that is sometimes hard to do with Qt)

If we follow these few practises, imho the codebase would already be much better.

@vimpostor commented on GitHub (May 25, 2020): OK, so I will keep this short as most stuff has already been said, but you can't stress this enough: I couldn't agree more with @Reikion, in fact I was going to post the same [article](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/). Particularly, I would like to highlight this paragraph: > Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. > When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. In short, it would be absolutely stupid to rewrite Mumble from scratch. Refactoring a code base to look nicer is absolutely always easier than rewriting it. I understand that Rust offers nice modern language features, but so does a recent C++ standard. From the few parts of Mumble that I have personally touched, I can see how the Mumble codebase is an utterly convoluted piece of dumbster fire. But, it is easier to refactor than rewrite Mumble, thus I would like to see the following: - Start using modern C++ - The code still uses C style memory management with `new` and `delete`, use smart pointers instead - It is fair to require C++17 in 2020 - There is no need to support very old Ubuntu LTS distros natively, their shipped library versions will hold back a modern codebase. Those distros can still be supported via other means like Appimage. - Start porting to Qt 6 as soon as possible, Mumble used Qt 4 for way too long - Some custom platform-specific code in Mumble can be ported to Qt API entirely, removing our own platform specific implementation - Generally, this codebase reeks of old stuff. I think it would be perfectly fine to only support the modern Opus codec for example. - Imho inheritance based OOP should be removed and be replaced with functional style interface-implementation based "OOP" like Rust or Haskell (though that is sometimes hard to do with Qt) If we follow these few practises, imho the codebase would already be much better.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 25, 2020):

I understand that Rust offers nice modern language features, but so does a recent C++ standard.

The main part about Rust is actually the safety guarantees it makes. You don't get that with c++

Some custom platform-specific code in Mumble can be ported to Qt API entirely, removing our own platform specific implementation

We actually want to move away from Qt as much as possible ^^

I also began wondering if it might be possible to get the best parts of both worlds. Doing a refactor but instead by doing so switching to Rust component by component. If we get our modularization ot a point at which the communication between the modules uses plain C API, it should be relatively easy to have some modules in Rust while others are still in c++ 🤔

@Krzmbrzl commented on GitHub (May 25, 2020): > I understand that Rust offers nice modern language features, but so does a recent C++ standard. The main part about Rust is actually the safety guarantees it makes. You don't get that with c++ > Some custom platform-specific code in Mumble can be ported to Qt API entirely, removing our own platform specific implementation We actually want to move away from Qt as much as possible ^^ ----- I also began wondering if it might be possible to get the best parts of both worlds. Doing a refactor but instead by doing so switching to Rust component by component. If we get our modularization ot a point at which the communication between the modules uses plain C API, it should be relatively easy to have some modules in Rust while others are still in c++ :thinking:

deekerman commented

Author

Owner

@vimpostor commented on GitHub (May 25, 2020):

Move away from Qt to where? Qt is still by far the most modern and feature complete native crossplatform GUI toolkit out there. I understand if you just mean separating backend from the frontend though (which might allow to write a Qt Quick based frontend, which could mean shipping Mumble to Android and iOS)

@vimpostor commented on GitHub (May 25, 2020): Move away from Qt to where? Qt is still by far the most modern and feature complete native crossplatform GUI toolkit out there. I understand if you just mean separating backend from the frontend though (which might allow to write a Qt Quick based frontend, which could mean shipping Mumble to Android and iOS)

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 25, 2020):

I also began wondering if it might be possible to get the best parts of both worlds. Doing a refactor but instead by doing so switching to Rust component by component. If we get our modularization ot a point at which the communication between the modules uses plain C API, it should be relatively easy to have some modules in Rust while others are still in c++ 🤔

I mean... it should be. That's what the people at Mozilla are doing with Firefox, for example. And in the Rust forums, the phrase "rewrite it in Rust" tends to be used more ironically since the actual best path tends to be what you are saying: take a piecemeal approach and rewrite it module by module.

Granted, this requires some level of pre existing modularization. Which from the comments on this thread seems to be lacking on the codebase. But maybe it can be achieved as "step 0" in the rewrite? And from then on a piecemeal rewrite could be achieved :)

@felix91gr commented on GitHub (May 25, 2020): > I also began wondering if it might be possible to get the best parts of both worlds. Doing a refactor but instead by doing so switching to Rust component by component. If we get our modularization ot a point at which the communication between the modules uses plain C API, it should be relatively easy to have some modules in Rust while others are still in c++ 🤔 I mean... it should be. That's what the people at Mozilla are doing with Firefox, for example. And in the Rust forums, the phrase "rewrite it in Rust" tends to be used more ironically since the actual best path tends to be what you are saying: take a piecemeal approach and rewrite it module by module. Granted, this requires some level of pre existing modularization. Which from the comments on this thread seems to be lacking on the codebase. But maybe it can be achieved as "step 0" in the rewrite? And from then on a piecemeal rewrite could be achieved :)

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 25, 2020):

Move away from Qt to where? Qt is still by far the most modern and feature complete native crossplatform GUI toolkit out there.

Yeah. We don't (necessarily) want to move away from Qt from the UI stuff, but we'd like to have a Qt free backend and server. This has to do with licensing and the path that Qt seems to have chosen recently in regards to FOSS...

@Krzmbrzl commented on GitHub (May 25, 2020): > Move away from Qt to where? Qt is still by far the most modern and feature complete native crossplatform GUI toolkit out there. Yeah. We don't (necessarily) want to move away from Qt from the UI stuff, but we'd like to have a Qt free backend and server. This has to do with licensing and the path that Qt seems to have chosen recently in regards to FOSS...

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 25, 2020):

Granted, this requires some level of pre existing modularization. Which from the comments on this thread seems to be lacking on the codebase. But maybe it can be achieved as "step 0" in the rewrite? And from then on a piecemeal rewrite could be achieved :)

My thinking exactly :)

@Krzmbrzl commented on GitHub (May 25, 2020): > Granted, this requires some level of pre existing modularization. Which from the comments on this thread seems to be lacking on the codebase. But maybe it can be achieved as "step 0" in the rewrite? And from then on a piecemeal rewrite could be achieved :) My thinking exactly :)

deekerman commented

Author

Owner

@fedetft commented on GitHub (May 25, 2020):

Dumbing down the components to a C API to play nice with rust's lack of C++ interoperability pretty much forbids using modern C++ though, and may introduce bugs/leaks instead of making Mumble safer...

In any case, I add a few "would be nice to have" to make Mumble easier to contribute to, which may be less shiny than a new language, but I believe are more essential:

An automated regression test suite on multiple palaforms. The current CI system compiles Mumble for all the platforms, but as far as I know it doesn't test them. In this PR https://github.com/mumble-voip/mumble/pull/4167 we're still discussing whether to remove a mutex that seems superfluous but may cause segfaults if some platform-dependent code calls two callbacks concurrently. Of course not every contributor has machines with Windows, Linux, Mac and *bsd to perform tests...
(Apologies if it's already there and I have not found it, I'm new to the project), a coding style autoformatter, such as clang-format to automate conforming to the Mumble coding style.

@fedetft commented on GitHub (May 25, 2020): Dumbing down the components to a C API to play nice with rust's lack of C++ interoperability pretty much forbids using modern C++ though, and may introduce bugs/leaks instead of making Mumble safer... In any case, I add a few "would be nice to have" to make Mumble easier to contribute to, which may be less shiny than a new language, but I believe are more essential: * An automated regression test suite on multiple palaforms. The current CI system compiles Mumble for all the platforms, but as far as I know it doesn't test them. In this PR https://github.com/mumble-voip/mumble/pull/4167 we're still discussing whether to remove a mutex that seems superfluous but may cause segfaults if some platform-dependent code calls two callbacks concurrently. Of course not every contributor has machines with Windows, Linux, Mac and *bsd to perform tests... * (Apologies if it's already there and I have not found it, I'm new to the project), a coding style autoformatter, such as clang-format to automate conforming to the Mumble coding style.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 25, 2020):

Dumbing down the components to a C API to play nice with rust's lack of C++ interoperability pretty much forbids using modern C++ though, and may introduce bugs/leaks instead of making Mumble safer...

My thinking basically was that internally a module may use the most fancy c++ ever but in terms of communication between modules it should work via C API in order to allow language bindings for arbitrary languages.
Besides I think there shouldn't be too much inter-module communication anyways (if it was needed the borders of what is a module should be reconsidered). Mostly I expect events to be passed between modules and for that I think a C API is enough 🤔

but as far as I know it doesn't test them

Not in a manner that's worth mentioning at least

(Apologies if it's already there and I have not found it, I'm new to the project), a coding style autoformatter, such as clang-format to automate conforming to the Mumble coding style.

No we don't have that yet. It'd probably be a nice addition though 👍

@Krzmbrzl commented on GitHub (May 25, 2020): > Dumbing down the components to a C API to play nice with rust's lack of C++ interoperability pretty much forbids using modern C++ though, and may introduce bugs/leaks instead of making Mumble safer... My thinking basically was that internally a module may use the most fancy c++ ever but in terms of communication between modules it should work via C API in order to allow language bindings for arbitrary languages. Besides I think there shouldn't be too much inter-module communication anyways (if it was needed the borders of what is a module should be reconsidered). Mostly I expect events to be passed between modules and for that I think a C API is enough :thinking: > but as far as I know it doesn't test them Not in a manner that's worth mentioning at least > (Apologies if it's already there and I have not found it, I'm new to the project), a coding style autoformatter, such as clang-format to automate conforming to the Mumble coding style. No we don't have that yet. It'd probably be a nice addition though :+1:

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 25, 2020):

Particularly, I would like to highlight this paragraph:

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

In short, it would be absolutely stupid to rewrite Mumble from scratch. Refactoring a code base to look nicer is absolutely always easier than rewriting it.

That kind of ignores that modularizing and improving the code will lead to similar issues as well. Any change may introduce issues. And improving and changing a code base without knowledge of the underlying issues and worked around issues will inevitably lead to the same issues as a rewrite in that regard.

The difference is 1. the degree to which this happens (because existing code may nudge you into problem cases and can be refactored including some workarounds even without knowing them by migrating that logic) and 2. that the changes are more gradual, and issues can be found step by step moreso than a complete rewrite and big switch.

@Kissaki commented on GitHub (May 25, 2020): > Particularly, I would like to highlight this paragraph: > > > Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. > > When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. > > In short, it would be absolutely stupid to rewrite Mumble from scratch. Refactoring a code base to look nicer is absolutely always easier than rewriting it. That kind of ignores that modularizing and improving the code will lead to similar issues as well. Any change may introduce issues. And improving and changing a code base without knowledge of the underlying issues and worked around issues will inevitably lead to the same issues as a rewrite in that regard. The difference is 1. the degree to which this happens (because existing code may nudge you into problem cases and can be refactored including some workarounds even without knowing them by migrating that logic) and 2. that the changes are more gradual, and issues can be found step by step moreso than a complete rewrite and big switch.

deekerman commented

Author

Owner

@fedetft commented on GitHub (May 25, 2020):

C APIs aren't fun to write and have their problems.

If you want to register a callback, limiting to a C API would mean a function taking a function pointer as argument. What if on the other side I want to register a lambda? Or a Member function?
In modern C++ I would use std::function/std::bind, which solves the issue, but it isn't a C API anymore...

Same with memory, when both sides of an API need to share some pointer we can use std::shared_ptr. or even excluding the shared ownership case C++ uses RAII in general, and limiting ourselves to a C API would introduce pointer ownership issues, leaks and double deletes...

And what about strings? std::string (again, imagining a core without Qt) is easier and safer than char*...

What I'm saying is that if there's a Qt UI on one side, and a C++ core on the other, going down to C and up again just makes everything harder, less fun to write and more unsafe.

@fedetft commented on GitHub (May 25, 2020): C APIs aren't fun to write and have their problems. If you want to register a callback, limiting to a C API would mean a function taking a function pointer as argument. What if on the other side I want to register a lambda? Or a Member function? In modern C++ I would use std::function/std::bind, which solves the issue, but it isn't a C API anymore... Same with memory, when both sides of an API need to share some pointer we can use std::shared_ptr. or even excluding the shared ownership case C++ uses RAII in general, and limiting ourselves to a C API would introduce pointer ownership issues, leaks and double deletes... And what about strings? std::string (again, imagining a core without Qt) is easier and safer than char*... What I'm saying is that if there's a Qt UI on one side, and a C++ core on the other, going down to C and up again just makes everything harder, less fun to write and more unsafe.

deekerman commented

Author

Owner

@streaps commented on GitHub (May 25, 2020):

In short, it would be absolutely stupid to rewrite Mumble from scratch.

Let's imagine what a true "from scratch" approach could look like:

let's rewrite the client
when we completely rewrite the client, maybe we should think about our current architecture and if that is still good enough for 2020
should we start from scratch?
how could stuff be better, if we could redesign everything: new protocol, new server?
protocol could be more extensible. we need a new server first
but what about p2p?
we have to think from the clients perspective
don't forget mobile devices. mobile first
PWA, iOS, Android, desktop. Flutter!
but first we need a good p2p architecture
p2p sucks on mobile
dumb mumble proxy servers on port 443/QUIC
everything has to be e2e encrypted, no metadata, no central authority
and we need notifications
for mobile the protocol should be stateless
we definitely have to start everything from scratch

@streaps commented on GitHub (May 25, 2020): > In short, it would be absolutely stupid to rewrite Mumble from scratch. Let's imagine what a true "from scratch" approach could look like: - let's rewrite the client - when we completely rewrite the client, maybe we should think about our current architecture and if that is still good enough for 2020 - should we start from scratch? - how could stuff be better, if we could redesign everything: new protocol, new server? - protocol could be more extensible. we need a new server first - but what about p2p? - we have to think from the clients perspective - don't forget mobile devices. mobile first - PWA, iOS, Android, desktop. Flutter! - but first we need a good p2p architecture - p2p sucks on mobile - dumb mumble proxy servers on port 443/QUIC - everything has to be e2e encrypted, no metadata, no central authority - and we need notifications - for mobile the protocol should be stateless - we definitely have to start everything from scratch

deekerman commented

Author

Owner

@theAkito commented on GitHub (May 25, 2020):

* don't forget mobile devices. mobile first

Couldn't disagree more with this. Mobile should be last.

@theAkito commented on GitHub (May 25, 2020): > * don't forget mobile devices. mobile first Couldn't disagree more with this. Mobile should be last.

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 25, 2020):

* don't forget mobile devices. mobile first
Couldn't disagree more with this. Mobile should be last.

Am I... are we bikeshedding on this?

I think mobile should not be last nor first. Think of the use-case: mobile lets you walk around the house, and walk around the city even. Where I live, my mobile internet is better than my house's broadband LAN.

Mobile lets you chill in a sofa. Mobile lets you do other stuff. For example, I personally tend to use videoconference software in my tablet, because it's so much more convenient. Even for work, when sitting on my computer.

I have wondered for the last few weeks if after graduating I should go ahead and try to make a cross platform (mobile) Mumble client, because I would value its existence too much. I'm still thinking about it.

Anywho. I don't think mobile should be last. Mobile has a strong role to fulfill, if you ask me.

@felix91gr commented on GitHub (May 25, 2020): > > ``` > > * don't forget mobile devices. mobile first > > ``` > > > Couldn't disagree more with this. Mobile should be last. Am I... are we bikeshedding on this? I think mobile should not be last nor first. Think of the use-case: mobile lets you walk around the house, and walk around the city even. Where I live, my mobile internet is better than my house's broadband LAN. Mobile lets you chill in a sofa. Mobile lets you do other stuff. For example, I personally tend to use videoconference software in my tablet, because it's so much more convenient. Even for work, _when_ sitting on my computer. I have wondered for the last few weeks if after graduating I should go ahead and try to make a cross platform (mobile) Mumble client, because I would value its existence too much. I'm still thinking about it. Anywho. I don't think mobile should be last. Mobile has a strong role to fulfill, if you ask me.

deekerman commented

Author

Owner

@fedetft commented on GitHub (May 25, 2020):

Those last two comments open an interesting side discussion: instead of talking code/bugs/safety, let's also discuss features!

I'm still using Mumble in 2020 despite some of my friends wanting me to switch to $alternative because it is free software, I can install it on my server, does one thing and has low maintenance.

That Mumble is free software and you can install it on your server I guess no one would want to change in the future, so let's discuss the other two.

My use case for mumble is what I call a virtual bar, a virtual place for friends to connect when they want, see who's there and chat, sometimes while gaming. What I would like from Mumble (which you may disagree of course) is to do that one thing better and better. Better voice quality through echo cancellation and noise suppression, mobile apps that receive as much support as the desktop version (hint hint: use the same core) for when you are not at the PC, and optional features that complement the one thing Mumble does well such as stereo background music, end-to-end encryption and an optional persistent chat would be what I would focus on.
Video calls, p2p, modular protocols that claim to do 1000 things but don't excel in anything and create vulnerabilities by extending the attack surface, the fact Mumble lacks them is what makes me choose it.

The low maintenance is also important for me. When installing it on a server you just open one TCP/UDP port, make a systemd script to run the deamon and you're done. It is also easy to put in a container/chroot due to the little dependencies for better safety.
Some of the alternative I've been suggested require to modify my nginx configuration because part of the protocol runs on port 80, setup a turn server, run a java app on the server (and upgrade the vps because I don't have enough RAM to run java), use an electron app on the client and I gave up many requirements before to be honest.

@fedetft commented on GitHub (May 25, 2020): Those last two comments open an interesting side discussion: instead of talking code/bugs/safety, let's also discuss features! I'm still using Mumble in 2020 despite some of my friends wanting me to switch to $alternative because it is free software, I can install it on my server, does one thing and has low maintenance. That Mumble is free software and you can install it on your server I guess no one would want to change in the future, so let's discuss the other two. My use case for mumble is what I call a virtual bar, a virtual place for friends to connect when they want, see who's there and chat, sometimes while gaming. What I would like from Mumble (which you may disagree of course) is to do that one thing better and better. Better voice quality through echo cancellation and noise suppression, mobile apps that receive as much support as the desktop version (hint hint: use the same core) for when you are not at the PC, and optional features that complement the one thing Mumble does well such as stereo background music, end-to-end encryption and an optional persistent chat would be what I would focus on. Video calls, p2p, modular protocols that claim to do 1000 things but don't excel in anything and create vulnerabilities by extending the attack surface, the fact Mumble lacks them is what makes me choose it. The low maintenance is also important for me. When installing it on a server you just open **one** TCP/UDP port, make a systemd script to run the deamon and you're done. It is also easy to put in a container/chroot due to the little dependencies for better safety. Some of the alternative I've been suggested require to modify my nginx configuration because part of the protocol runs on port 80, setup a turn server, run a java app on the server (and upgrade the vps because I don't have enough RAM to run java), use an electron app on the client and I gave up many requirements before to be honest.

deekerman commented

Author

Owner

@timokoesters commented on GitHub (May 25, 2020):

I'd like some easier way to send images and permanent messages. What I would like even more is not doing that and instead having good integration with an open source messaging program like Matrix (https://matrix.org) with the Riot client (https://riot.im).

@timokoesters commented on GitHub (May 25, 2020): I'd like some easier way to send images and permanent messages. What I would like even more is **not** doing that and instead having good integration with an open source messaging program like Matrix (https://matrix.org) with the Riot client (https://riot.im).

deekerman commented

Author

Owner

@streaps commented on GitHub (May 25, 2020):

goto https://github.com/Johni0702/mumble-web

@streaps commented on GitHub (May 25, 2020): goto https://github.com/Johni0702/mumble-web

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 25, 2020):

Should we really be discussing feature set here? Maybe it deserves its own thread.

Leave 👍 at this comment for Yes, we should be discussing new features here,
And leave 👎 for No, I'd rather have a separate thread.

I'll make a new thread if you'd rather separate the two topics.

@felix91gr commented on GitHub (May 25, 2020): Should we really be discussing feature set here? Maybe it deserves its own thread. Leave :+1: at this comment for Yes, we should be discussing new features here, And leave :-1: for No, I'd rather have a separate thread. I'll make a new thread if you'd rather separate the two topics.

deekerman commented

Author

Owner

@theAkito commented on GitHub (May 25, 2020):

@felix91gr

I'd like to answer you in a separate issue/thread. 😁

@theAkito commented on GitHub (May 25, 2020): @felix91gr I'd like to answer you in a separate issue/thread. 😁

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 25, 2020):

(Imma wait for a larger quorum, because of timezones!)

@felix91gr commented on GitHub (May 25, 2020): (Imma wait for a larger quorum, because of timezones!)

deekerman commented

Author

Owner

@streaps commented on GitHub (May 25, 2020):

My "from scratch" comment was meant to be irony and as an illustration of one side of the rewrite-from-scratch spectrum.

I don't think that the idea of rewriting the client is stupid and I wouldn't be surprised, if it's less work with better result than trying to refactor the current Mumble client. I don't believe Joel Spolsky's idea of the "single worst strategic mistake" applies here. If you keep the protocol, if you keep the server and compatibility, you have most of the design that evolved over the time still baked in.

It's really not the client that is spectacular and glorious (IMHO). It's the ecosystem and the protocol. The server that is easy to install and setup, the flexibility with ACLs, the low overhead and that it just works most of the time. I can use Mumble on a very old Android phone with a 32 kbps connection (1:1 conversations) and it doesn't sound bad.

Rewriting the client without changing anything else is some kind of "refactoring" too, in a broader sense.

@streaps commented on GitHub (May 25, 2020): My "from scratch" comment was meant to be irony and as an illustration of one side of the rewrite-from-scratch spectrum. I don't think that the idea of rewriting the client is stupid and I wouldn't be surprised, if it's less work with better result than trying to refactor the current Mumble client. I don't believe Joel Spolsky's idea of the "single worst strategic mistake" applies here. If you keep the protocol, if you keep the server and compatibility, you have most of the design that evolved over the time still baked in. It's really not the client that is spectacular and glorious (IMHO). It's the ecosystem and the protocol. The server that is easy to install and setup, the flexibility with ACLs, the low overhead and that it just works most of the time. I can use Mumble on a very old Android phone with a 32 kbps connection (1:1 conversations) and it doesn't sound bad. Rewriting the client without changing anything else is some kind of "refactoring" too, in a broader sense.

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 25, 2020):

To add some data to the Rust (or limitation to more modern and restricted C++?) may provide increased safety argument, or at least point at it’s significance:

Chromium says

Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.
(Analysis based on 912 high or critical severity security bugs since 2015, affecting the Stable channel.)

Microsoft Security Response Center says

~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues

@Kissaki commented on GitHub (May 25, 2020): To add some data to the Rust (or limitation to more modern and restricted C++?) may provide increased safety argument, or at least point at it’s significance: Chromium [says](https://www.chromium.org/Home/chromium-security/memory-safety) > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. > (Analysis based on 912 high or critical severity security bugs since 2015, affecting the Stable channel.) Microsoft Security Response Center [says](https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/) > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 25, 2020):

(Imma wait for a larger quorum, because of timezones!)

Imma vote for putting it in a separate thread, and by 5 to 0, I think we should move the feature wishlist to another issue.

I will update y'all with a link to it after I make it. Brb!

@felix91gr commented on GitHub (May 25, 2020): > (Imma wait for a larger quorum, because of timezones!) Imma vote for putting it in a separate thread, and by 5 to 0, I think we should move the feature wishlist to another issue. I will update y'all with a link to it after I make it. Brb!

deekerman commented

Author

Owner

@felix91gr commented on GitHub (May 25, 2020):

The issue is up here: https://github.com/mumble-voip/mumble/issues/4207

@felix91gr commented on GitHub (May 25, 2020): The issue is up here: https://github.com/mumble-voip/mumble/issues/4207

deekerman commented

Author

Owner

@TredwellGit commented on GitHub (May 28, 2020):

I would like to contribute, but am not sure how much time I would be able to dedicate.

Some comments:

Is there a Mumble server for discussing Mumble development?
I am strongly in preference to using memory and thread safe languages. As stated earlier, this would just eliminate a large number of security issues.
Although I have never used it, there is already a Mumble server written in Rust. https://github.com/SpaceManiac/hullrot
I found this project a while back; maybe it could be useful? https://github.com/roc-project/roc

@TredwellGit commented on GitHub (May 28, 2020): I would like to contribute, but am not sure how much time I would be able to dedicate. Some comments: - Is there a Mumble server for discussing Mumble development? - I am strongly in preference to using memory and thread safe languages. As stated earlier, this would just eliminate a large number of security issues. - Although I have never used it, there is already a Mumble server written in Rust. https://github.com/SpaceManiac/hullrot - I found this project a while back; maybe it could be useful? https://github.com/roc-project/roc

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 28, 2020):

Is there a Mumble server for discussing Mumble development?

There's the #mumble-dev channel on IRC

@Krzmbrzl commented on GitHub (May 28, 2020): > Is there a Mumble server for discussing Mumble development? There's the #mumble-dev channel on IRC

deekerman commented

Author

Owner

@pascaldornfeld commented on GitHub (May 28, 2020):

What about Java as client language? It is platform independent and so widespread. Like every student here learns Java in highschool. This is why it can be very appealing to new supporters. It can easily run on Windows, Linux and Mac (most likely on a refrigerator too). Most of the code could be reused for Android.
I am only talking about the client. I can imagine it is not well-suited for the server code. There are pros and cons of having the client and server in different languages.

@pascaldornfeld commented on GitHub (May 28, 2020): What about Java as client language? It is platform independent and so widespread. Like every student here learns Java in highschool. This is why it can be very appealing to new supporters. It can easily run on Windows, Linux and Mac (most likely on a refrigerator too). Most of the code could be reused for Android. I am only talking about the client. I can imagine it is not well-suited for the server code. There are pros and cons of having the client and server in different languages.

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 28, 2020):

Rust GUI information/libs information https://areweguiyet.com/

@Kissaki commented on GitHub (May 28, 2020): Rust GUI information/libs information https://areweguiyet.com/

deekerman commented

Author

Owner

@Kissaki commented on GitHub (May 28, 2020):

Java is widespread mostly for backend services, not GUI or server software.

I don’t think that that it is teached widely is a good enough reason to pick it over others. Given that no team member has even mentioned it yet as a candidate is a pretty clear indicator that it is unlikely we will chose it.

@Kissaki commented on GitHub (May 28, 2020): Java is widespread mostly for backend services, not GUI or server software. I don’t think that that it is teached widely is a good enough reason to pick it over others. Given that no team member has even mentioned it yet as a candidate is a pretty clear indicator that it is unlikely we will chose it.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (May 29, 2020):

Personally I really like Java. It was the first proper language I learned and I used it for many years (still do occasionally).

The thing with realtime audio applications however is that they need to be as fast as possible (the audio part at least) and Java excels at many things but speed is not one of them.
While it would probably work fine for most parts of the client, I think it is not really suited for the audio-portion which is basically the heart of Mumble.

Java is widespread mostly for backend services, not GUI or server software.

There are decent GUI frameworks though. Like SWT

@Krzmbrzl commented on GitHub (May 29, 2020): Personally I really like Java. It was the first proper language I learned and I used it for many years (still do occasionally). The thing with realtime audio applications however is that they need to be as fast as possible (the audio part at least) and Java excels at many things but speed is not one of them. While it would probably work fine for most parts of the client, I think it is not really suited for the audio-portion which is basically the heart of Mumble. > Java is widespread mostly for backend services, not GUI or server software. There are decent GUI frameworks though. Like SWT

deekerman commented

Author

Owner

@pascaldornfeld commented on GitHub (May 29, 2020):

Personally I really like Java. It was the first proper language I learned and I used it for many years (still do occasionally).

The thing with realtime audio applications however is that they need to be as fast as possible (the audio part at least) and Java excels at many things but speed is not one of them.
While it would probably work fine for most parts of the client, I think it is not really suited for the audio-portion which is basically the heart of Mumble.

Java is widespread mostly for backend services, not GUI or server software.

There are decent GUI frameworks though. Like SWT

Sure, there are the older GUI Frameworks AWT and SWT and the newer JavaFX. I just remember that the famous IDE eclipse is done in Java. You can use native C code in Java but I agree that Java is not as fast as C.

@pascaldornfeld commented on GitHub (May 29, 2020): > Personally I really like Java. It was the first proper language I learned and I used it for many years (still do occasionally). > > The thing with realtime audio applications however is that they need to be as fast as possible (the audio part at least) and Java excels at many things but speed is not one of them. > While it would probably work fine for most parts of the client, I think it is not really suited for the audio-portion which is basically the heart of Mumble. > > > Java is widespread mostly for backend services, not GUI or server software. > > There are decent GUI frameworks though. Like SWT Sure, there are the older GUI Frameworks AWT and SWT and the newer JavaFX. I just remember that the famous IDE eclipse is done in Java. You can use native C code in Java but I agree that Java is not as fast as C.

deekerman commented

Author

Owner

@TBombadil commented on GitHub (May 31, 2020):

I share both enthusiasm and scepticism for a rewrite, so here are some thoughts applicable to both.

My perspective as a (somewhat recent) Mumble user

I loosely followed the development of Mumble 1.3. for several (>6?) years, because I made my friends promise to switch from Teamspeak 3 to Mumble. To me, Mumble seemed to be in a "zombie" state for several years. I never expected any new features, let alone feature/usability parity with TS 3.
So I don't think rewriting (from scratch or in parts) will affect your remaining userbase too much. (Perhaps, this sounds harsh, but it's only a matter of fact statement of my pov. I really do appreciate your work on Mumble.)
If needed, I may be able to help a bit with crypto-related stuff. But I'm don't have much programming experience, nor do I have practical security experience.

Backwards compatibility

I saw many changes (resp. complicated code) which were not made (resp. kept) for backwards compatibility. Why do you strive for such strong compatibility guarantees? I'm not advertising to "move fast and break things", but you're in a position where maintainability seems more important than compatibility (and even features).
Why not remove bad stuff? Case in point: https://github.com/mumble-voip/mumble/pull/2590
A lot of people are used frequent updates. Breaking changes are acceptable, as long as you give comprehensible errors to users and have a well-built upgrade path for Mumble.

Learn from GNOME/GDK (but not too much).

GNOME/GDK break stuff and don't care too much about what users think. (For these reasons, maybe GDK is not a good choice for UI, but maybe GDK is more stable now.)

Rewrite from scratch: target audience

Do you plan do give up/break compatibility with Mumble/the Mumble protocol? If you do, then question everything, and don't just reimplement features.
Are your target audience still primarily gamers? I've never used the gaming related features. So how important is game-overlay, coordinate grabbing, positional audio? (Can it be postponed for a rewrite?) Can ACLs be just left to scripting, or are they so trivial to implement and useful, that we want them? How important is mobile?

Measure

Do you have any means to get feedback from Mumble users, so you can sort them into rough profiles and see what's best part of Mumble, and what can be relegated to plugins?

Modularize

AFAICS, you already plan to do this. Here's my take on it. Basic idea: Split into stable (e.g. libs) and less stable blocks (e.g. GUI), and be plugin-friendly. Keep "default Mumble" small and maintainable.

Server: Seems to already exist with Grumble?
Client (lib): Core functionality.
Audio/Video: Not sure if this is part of Core, GUI, or separate lib. (DSP is core-like. But IO (Win/Mac/Alsa/PA/...) is GUI-like.)
GUI: Mumble's "default" GUI, built on Core+AV.
Administration: Do we need administration features in GUI? Can we keep it minimal? Separate interface (CLI/Web-based/Plugin) for more complex administration? Probably, users either use very little, or a lot of administration (including scripting).
Game-position plugin: Separate process? Not part of core! (I never used it, but saw many issues.)
Overlay: Separate lib/plugin. (Do people use this?)

For library communication: What about "standardized interfaces" instead of a C-API (exposed via C-API, or IPC). E.g., use protobufs/flatbufs/capnproto, or even XML/JSON for non-critical tasks, e.g. scripting. This way, your interface is less language-dependent.

@TBombadil commented on GitHub (May 31, 2020): I share both enthusiasm and scepticism for a rewrite, so here are some thoughts applicable to both. ### My perspective as a (somewhat recent) Mumble user I loosely followed the development of Mumble 1.3. for several (>6?) years, because I made my friends promise to switch from Teamspeak 3 to Mumble. To me, Mumble seemed to be in a "zombie" state for several years. I never expected any new features, let alone feature/usability parity with TS 3. So I don't think rewriting (from scratch or in parts) will affect your remaining userbase too much. (Perhaps, this sounds harsh, but it's only a matter of fact statement of my pov. I really do appreciate your work on Mumble.) If needed, I may be able to help a bit with crypto-related stuff. But I'm don't have much programming experience, nor do I have practical security experience. ### Backwards compatibility I saw many changes (resp. complicated code) which were not made (resp. kept) for backwards compatibility. Why do you strive for such strong compatibility guarantees? I'm not advertising to "move fast and break things", but you're in a position where maintainability seems more important than compatibility (and even features). Why not remove bad stuff? Case in point: https://github.com/mumble-voip/mumble/pull/2590 A lot of people are used frequent updates. Breaking changes are acceptable, as long as you give comprehensible errors to users and have a well-built upgrade path for Mumble. #### Learn from GNOME/GDK (but not too much). GNOME/GDK break stuff and don't care too much about what users think. (For these reasons, maybe GDK is not a good choice for UI, but maybe GDK is more stable now.) ### Rewrite from scratch: target audience Do you plan do give up/break compatibility with Mumble/the Mumble protocol? If you do, then *question everything*, and don't just reimplement features. Are your target audience still primarily gamers? I've never used the gaming related features. So how important is game-overlay, coordinate grabbing, positional audio? (Can it be postponed for a rewrite?) Can ACLs be just left to scripting, or are they so trivial to implement and useful, that we want them? How important is mobile? #### Measure Do you have any means to get feedback from Mumble users, so you can sort them into rough profiles and see what's best part of Mumble, and what can be relegated to plugins? ### Modularize AFAICS, you already plan to do this. Here's my take on it. Basic idea: Split into stable (e.g. libs) and less stable blocks (e.g. GUI), and be plugin-friendly. Keep "default Mumble" small and maintainable. + Server: Seems to already exist with Grumble? + Client (lib): Core functionality. + Audio/Video: Not sure if this is part of Core, GUI, or separate lib. (DSP is core-like. But IO (Win/Mac/Alsa/PA/...) is GUI-like.) + GUI: Mumble's "default" GUI, built on Core+AV. + Administration: Do we need administration features in GUI? Can we keep it minimal? Separate interface (CLI/Web-based/Plugin) for more complex administration? Probably, users either use very little, or a lot of administration (including scripting). + Game-position plugin: Separate process? Not part of core! (I never used it, but saw many issues.) + Overlay: Separate lib/plugin. (Do people use this?) For library communication: What about "standardized interfaces" instead of a C-API (exposed via C-API, or IPC). E.g., use protobufs/flatbufs/capnproto, or even XML/JSON for non-critical tasks, e.g. scripting. This way, your interface is less language-dependent.

deekerman commented

Author

Owner

@dpy013 commented on GitHub (May 31, 2020):

hello all
After reading all the comments above, I personally support refactoring mumble. But overthrowing them all is a pain for developers.
We can keep the bottom mumble, and the upper layer uses electron for reconstruction.
This gives consideration to both ease of use and cross-platform.
In the process of refactoring, it is recommended to use the c ++ 20 standard.

@dpy013 commented on GitHub (May 31, 2020): hello all After reading all the comments above, I personally support refactoring mumble. But overthrowing them all is a pain for developers. We can keep the bottom mumble, and the upper layer uses electron for reconstruction. This gives consideration to both ease of use and cross-platform. In the process of refactoring, it is recommended to use the c ++ 20 standard.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jun 1, 2020):

@TBombadil

as long as you give comprehensible errors to users and have a well-built upgrade path for Mumble.

This I think is the critical part here. We don't have that at least on Linux where Distros tend to just freeze old packages and don't allow for feature updates during the Distro's lifetime.

Furthermore if someone was using Mumble in a more professional environment (say a company) they'd not be too happy if Mumble broke every half a year or so, even if there are updates available.

And last but not least: There are quite a few 3rdParty libraries out there that interface with Mumble. If we make breaking changes, we basically tell every external library dev "f*ck you, we don't care about you" as in that case they really have to constantly check whether Mumble has broken something again and if so, they'll have to patch it up.

Besides: Having an open protocol is not worth anything if you constantly break things.

What about "standardized interfaces" instead of a C-API (exposed via C-API, or IPC). E.g., use protobufs/flatbufs/capnproto, or even XML/JSON for non-critical tasks, e.g. scripting. This way, your interface is less language-dependent.

First off: By using a C-API the API would be pretty much language independent as basically every language has the ability to interface with C somehow.

Using XML and/or JSON and/or any other plain text format imo is the way to go for an API like server management (e.g. in form of a REST API), but it is no way to actually provide an API for programs that run on the same machine and might be interested in doing some more time critical stuff. Now you said we could split the API but I guess that'd just make it more work for us to develop and maintain it. Furthermore it'd be confusing for a 3rdParty dev that now has to check which functionality is put into which API.

Using Protobuf as the API might be an idea but I still think the C-API approach might be better suited as it allows to get things done with less overhead. Also it could then be used to let Mumble parts themselves be plugged in and out because they basically work as a plugin (e.g. the overlay could be working this way) - the point here is that you really don't want to have the communication within the program to go through protobuf all the time but with a C API it should work quite well.

@dingpengyu

In the process of refactoring, it is recommended to use the c ++ 20 standard.

Afaik not even all compilers support it yet in the stable branch, let alone any compiler that is not bleeding edge. I am a big fan of using new stuff but I don't think cpp20 should be used for projects like this until a few years in the future...

@Krzmbrzl commented on GitHub (Jun 1, 2020): @TBombadil > as long as you give comprehensible errors to users and have a well-built upgrade path for Mumble. This I think is the critical part here. We don't have that at least on Linux where Distros tend to just freeze old packages and don't allow for feature updates during the Distro's lifetime. Furthermore if someone was using Mumble in a more professional environment (say a company) they'd not be too happy if Mumble broke every half a year or so, even if there are updates available. And last but not least: There are quite a few 3rdParty libraries out there that interface with Mumble. If we make breaking changes, we basically tell every external library dev "f*ck you, we don't care about you" as in that case they really have to constantly check whether Mumble has broken something again and if so, they'll have to patch it up. Besides: Having an open protocol is not worth anything if you constantly break things. > What about "standardized interfaces" instead of a C-API (exposed via C-API, or IPC). E.g., use protobufs/flatbufs/capnproto, or even XML/JSON for non-critical tasks, e.g. scripting. This way, your interface is less language-dependent. First off: By using a C-API the API would be pretty much language independent as basically every language has the ability to interface with C somehow. Using XML and/or JSON and/or any other plain text format imo is the way to go for an API like server management (e.g. in form of a REST API), but it is no way to actually provide an API for programs that run on the same machine and might be interested in doing some more time critical stuff. Now you said we could split the API but I guess that'd just make it more work for us to develop and maintain it. Furthermore it'd be confusing for a 3rdParty dev that now has to check which functionality is put into which API. Using Protobuf as the API might be an idea but I still think the C-API approach might be better suited as it allows to get things done with less overhead. Also it could then be used to let Mumble parts themselves be plugged in and out because they basically work as a plugin (e.g. the overlay could be working this way) - the point here is that you really don't want to have the communication within the program to go through protobuf all the time but with a C API it should work quite well. @dingpengyu > In the process of refactoring, it is recommended to use the c ++ 20 standard. Afaik not even all compilers support it yet in the stable branch, let alone any compiler that is not bleeding edge. I am a big fan of using new stuff but I don't think cpp20 should be used for projects like this until a few years in the future...

deekerman commented

Author

Owner

@TBombadil commented on GitHub (Jun 2, 2020):

From what I understand, you "only" want to rewrite Mumble.I misunderstood and thought you wanted to "reinvent" Mumble with new features which would require breaking changes, or a lot of compatibility code.
My comments were for this case, and the short-term goal of a rewrite. Long-term, compatibility shouldn't break too often. But in the first few years of development, it's probably better than getting into a mess. As for the GDK example, they certainly don't break compatibility without a reason, but because they believe the gain outweighs the loss.
Well, perhaps, it's just me who's severely underestimating the importance of stability.

as long as you give comprehensible errors to users and have a well-built upgrade path for Mumble.

This I think is the critical part here. We don't have that at least on Linux where Distros tend to just freeze old packages and don't allow for feature updates during the Distro's lifetime.

I agree with that problem, but am not sure if it's applicable.

Furthermore if someone was using Mumble in a more professional environment (say a company) they'd not be too happy if Mumble broke every half a year or so, even if there are updates available.

That means professional environments/companies are part of your target group. (I did not think that was the case.)

And last but not least: There are quite a few 3rdParty libraries out there that interface with Mumble.
If we make breaking changes, we basically tell every external library dev "f*ck you, we don't care about you" as in that case they really have to constantly check whether Mumble has broken something again and if so, they'll have to patch it up.

Besides: Having an open protocol is not worth anything if you constantly break things.

Honestly, from a stability point-of-view, the API and protocol are obviously the most important parts, which should preserve backwards compatibility and slowly deprecate, whenever that is possible without excessive overhead.

Regarding JSON interfaces: IIRC, that's what the Xi editor uses with the argument that it makes plugins simple. For efficiency reasons, I wouldn't want (all of) core to use that. AFAIK, protobuf supports compatibility stuff, that's why I thought it may be useful (so that the C-API can be upgraded with new features without breaking older extensions.). But Mumble developers definitely know better what's needed than I do.

@TBombadil commented on GitHub (Jun 2, 2020): From what I understand, you "only" want to rewrite Mumble.I misunderstood and thought you wanted to "reinvent" Mumble with new features which would require breaking changes, or a lot of compatibility code. My comments were for this case, and the short-term goal of a rewrite. Long-term, compatibility shouldn't break too often. But in the first few years of development, it's probably better than getting into a mess. As for the GDK example, they certainly don't break compatibility without a reason, but because they believe the gain outweighs the loss. Well, perhaps, it's just me who's severely underestimating the importance of stability. > > as long as you give comprehensible errors to users and have a well-built upgrade path for Mumble. > > This I think is the critical part here. We don't have that at least on Linux where Distros tend to just freeze old packages and don't allow for feature updates during the Distro's lifetime. I agree with that problem, but am not sure if it's applicable. > Furthermore if someone was using Mumble in a more professional environment (say a company) they'd not be too happy if Mumble broke every half a year or so, even if there are updates available. That means professional environments/companies are part of your target group. (I did not think that was the case.) > And last but not least: There are quite a few 3rdParty libraries out there that interface with Mumble. If we make breaking changes, we basically tell every external library dev "f*ck you, we don't care about you" as in that case they really have to constantly check whether Mumble has broken something again and if so, they'll have to patch it up. > > Besides: Having an open protocol is not worth anything if you constantly break things. Honestly, from a stability point-of-view, the API and protocol are obviously the most important parts, which should preserve backwards compatibility and slowly deprecate, whenever that is possible without excessive overhead. Regarding JSON interfaces: IIRC, that's what the Xi editor uses with the argument that it makes plugins simple. For efficiency reasons, I wouldn't want (all of) core to use that. AFAIK, protobuf supports compatibility stuff, that's why I thought it may be useful (so that the C-API can be upgraded with new features without breaking older extensions.). But Mumble developers definitely know better what's needed than I do.

deekerman commented

Author

Owner

@Chris2000SP commented on GitHub (Jun 6, 2020):

@Krzmbrzl

@TBombadil

as long as you give comprehensible errors to users and have a well-built upgrade path for Mumble.

This I think is the critical part here. We don't have that at least on Linux where Distros tend to just freeze old packages and don't allow for feature updates during the Distro's lifetime.

Furthermore if someone was using Mumble in a more professional environment (say a company) they'd not be too happy if Mumble broke every half a year or so, even if there are updates available.

And last but not least: There are quite a few 3rdParty libraries out there that interface with Mumble. If we make breaking changes, we basically tell every external library dev "f*ck you, we don't care about you" as in that case they really have to constantly check whether Mumble has broken something again and if so, they'll have to patch it up.

Besides: Having an open protocol is not worth anything if you constantly break things.

I'm Mumble User since 1.1.x and i am a fan of stability and speed of this app. I'm not a developer yet, but I vote for refactoring Mumble and not rewriting. I have used Mumble for 12 years and I would be disappointed if Mumble was not what it is now. But I can do without overlay and positional audio. I would prefer to have the Echo Cancel fixed. Many people get scared when an audio feedback to a loud whistling from the speakers sounds and they say I can't handle it. Mumble needs to be made more user-friendly. As far as the ACLs are concerned, I'm a big fan of them, because I was able to do something with them that I can't do in any other program. But if there is an idea to make it easier to do, and without loss of features, then so be it.

Sorry for answering so late.

@Chris2000SP commented on GitHub (Jun 6, 2020): @Krzmbrzl > @TBombadil > > > as long as you give comprehensible errors to users and have a well-built upgrade path for Mumble. > > This I think is the critical part here. We don't have that at least on Linux where Distros tend to just freeze old packages and don't allow for feature updates during the Distro's lifetime. > > Furthermore if someone was using Mumble in a more professional environment (say a company) they'd not be too happy if Mumble broke every half a year or so, even if there are updates available. > > And last but not least: There are quite a few 3rdParty libraries out there that interface with Mumble. If we make breaking changes, we basically tell every external library dev "f*ck you, we don't care about you" as in that case they really have to constantly check whether Mumble has broken something again and if so, they'll have to patch it up. > > Besides: Having an open protocol is not worth anything if you constantly break things. I'm Mumble User since 1.1.x and i am a fan of stability and speed of this app. I'm not a developer yet, but I vote for refactoring Mumble and not rewriting. I have used Mumble for 12 years and I would be disappointed if Mumble was not what it is now. But I can do without overlay and positional audio. I would prefer to have the Echo Cancel fixed. Many people get scared when an audio feedback to a loud whistling from the speakers sounds and they say I can't handle it. Mumble needs to be made more user-friendly. As far as the ACLs are concerned, I'm a big fan of them, because I was able to do something with them that I can't do in any other program. But if there is an idea to make it easier to do, and without loss of features, then so be it. Sorry for answering so late.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jun 7, 2020):

I would prefer to have the Echo Cancel fixed.

It actually got fixed very recently. The fixed version will be shipped with 1.4.0 :)

Sorry for answering so late.

No problem

@Krzmbrzl commented on GitHub (Jun 7, 2020): > I would prefer to have the Echo Cancel fixed. It actually got fixed very recently. The fixed version will be shipped with 1.4.0 :) > Sorry for answering so late. No problem

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jun 7, 2020):

We (the Team) want to thank you all for the input you have provided and also for the constructive criticism.

We had another Team-Meeting yesterday and in short this is what came out of it:

Refactor

We decided to go with refactoring instead of rewriting due to not having to stop development for time X until the rewrite is done but incrementally improve the code base instead.

It must be noted however that "refactoring" in the context of the current code base means nothing else than "continuous rewrite" (as there is just so much to improve). Therefore the argument of a refactor not introducing new bugs can not be applied to our case here.
Nonetheless the "refactor" provides the advantage that we can rewrite a certain (small) part of the system and then apply that change to master and ship snapshots and releases with it which hopefully allows us to catch errors early on.

C++

We also decided to stay with C++.

This is due to a variety of reasons but most prominently: The existing code base is written in c++ already and thus it's easiest to continue using c++ for the refactoring.
In addition to that only a minority of the active core-developers did actually like the idea of learning a new language (Rust) and it all is worth nothing if we project dies due to nobody wanting to work on it anymore.

That being said however we do realize that Rust's philosophy does provide very, very useful concepts that'll help improving the code quality and easing maintenance work.
Therefore we want to integrate as much of these concepts as possible into our c++ code base. We plan to do so by using modern c++ styles (modern types, especially smart-pointers) and we also want to heavily integrate static analysis.
With that we are hoping that we can get some of the guarantees Rust makes into c++ as well.

The process of how we want to achieve that is not entirely set yet. I'll create a follow-up ticket here on GitHub (today or tomorrow) in which I'll outline the possibilities that we have thought of and I would like to invite everyone to have a look and contribute new ideas or comment on existing ones :)

@Krzmbrzl commented on GitHub (Jun 7, 2020): We (the Team) want to thank you all for the input you have provided and also for the constructive criticism. We had another Team-Meeting yesterday and in short this is what came out of it: ## Refactor We decided to go with refactoring instead of rewriting due to not having to stop development for time X until the rewrite is done but incrementally improve the code base instead. It must be noted however that "refactoring" in the context of the current code base means nothing else than "continuous rewrite" (as there is just so much to improve). Therefore the argument of a refactor not introducing new bugs can not be applied to our case here. Nonetheless the "refactor" provides the advantage that we can rewrite a certain (small) part of the system and then apply that change to master and ship snapshots and releases with it which hopefully allows us to catch errors early on. ## C++ We also decided to stay with C++. This is due to a variety of reasons but most prominently: The existing code base is written in c++ already and thus it's easiest to continue using c++ for the refactoring. In addition to that only a minority of the active core-developers did actually like the idea of learning a new language (Rust) and it all is worth nothing if we project dies due to nobody wanting to work on it anymore. That being said however we do realize that Rust's philosophy does provide very, very useful concepts that'll help improving the code quality and easing maintenance work. Therefore we want to integrate as much of these concepts as possible into our c++ code base. We plan to do so by using modern c++ styles (modern types, especially smart-pointers) and we also want to heavily integrate static analysis. With that we are hoping that we can get some of the guarantees Rust makes into c++ as well. The process of how we want to achieve that is not entirely set yet. I'll create a follow-up ticket here on GitHub (today or tomorrow) in which I'll outline the possibilities that we have thought of and I would like to invite everyone to have a look and contribute new ideas or comment on existing ones :)

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jun 7, 2020):

See #4261 for the discussion about how to make sure Mumble's c++ code base will get future-proof ☝️

@Krzmbrzl commented on GitHub (Jun 7, 2020): See #4261 for the discussion about how to make sure Mumble's c++ code base will get future-proof :point_up:

deekerman commented