Mumble rewrite #4195
Comments
Programming LanguageIf we really do a rewrite from scratch, we can start this thread by a discussion on what programming language could be used for this. The obvious choice here would be c++ as that's what Mumble is currently written in. However other viable choices might include Rust and Go (which is what the grumble server implementation is written in). As an input for this discussion I would like to refer to [the StackOverflow survey from 2019[https://insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted] where people's most loved/dreaded programming languages are listed. According to this Rust is the overall most loved programming language, Go is 9th and c++ is 19th. According to these numbers it might be a good idea to switch to Rust if we want to attract as many new devs as possible. 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. Considering that we are having lots of problems with data races (and also some with memory management/safety) I guess this is a huge point to consider here. Also it seems to be possible to include C/C++ code into Rust which might be important for including our dependencies. On the Go-side I have been told that it excels at writing highly concurrent code. On the flip-side though it uses a garbage collector which might slow things down. I have been told though that compared to other managed languages, Go is way faster. I'd really like to get some opinions here. Maybe especially from people that actually have experience with these languages. I myself have worked with c++ for a while now and I also have briefly touched Rust once. Therefore it might be valuable to get input from folks that really know what they're talking about ^^ /cc @actown, @felix91gr |
|
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
It also provides a guarantee of no Undefined Behavior in its safe subset, which is all that you need for most applications! :)
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:
My experience from using it in large codebasesI'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:
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 :) |
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! :) |
|
Thank you for the input on Rust. Much appreciated! |
Drop & RewriteStarting 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 LanguageIs 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. |
|
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. |
Drop & RewriteYou are of course correct @Kissaki that a complete rewrite does indeed bring some risks with it and time-management is definitely a concern here. 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). 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.
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
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.
Absolutely. we should definitely not count on that too much. Nonetheless it's something to consider.
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'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 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.
This is of course a valid argument. I think Rust isn't too bad on that end (the tooling) either, though 🤔 |
|
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. EDIT: That blog post is a good read for anyone not too familiar with Rust in any case. Very informative. |
|
Rust also has excellent documentation (the book, std lib, docs.rs) and a pretty active discord channel |
|
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. |
|
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
I guess it would make sense to share networking code between client and server to a degree. So maybe then it would be
|
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. |
I loved the error messages when I was using it. :) |
|
@Krzmbrzl, sorry for being silent for a few days, but I'm alive and please add me to the list :D (I have no access to IRC through Monday) |
|
Very promising idea 👍 Disclaimer: I am not a programmer, so maybe I just talk nonsense 😄 I see some clear Advantages:
Still there are some open questions:
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:
Some specifics:
I advice against that. @Krzmbrzl mentioned:
Sounds good 👍. Some other points and ideas to add:
|
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.
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.
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.
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.
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.
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.
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)
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. |
Drop & RewriteI recommend to read https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
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 LanguageI'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:
|
|
@Krzmbrzl |
|
What about Vala and/or GObject C for the backend? |
|
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. LanguageI'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 codebaseI 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! Why 2 bool and not and enum. And why AudioInput declares those: and checks for 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. 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. |
|
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... |
|
@Reikion
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 🙂 |
|
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. |
|
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. |
|
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. |
Refactor vs. RewriteI 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. 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...
@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).
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
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.
Never heard of these languages.
@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
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
I fully agree with that.
@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
@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). |
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 |
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. |
|
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). |
|
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, I'll make a new thread if you'd rather separate the two topics. |
|
I'd like to answer you in a separate issue/thread. 😁 |
|
(Imma wait for a larger quorum, because of timezones!) |
|
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. |
|
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
Microsoft Security Response Center says
|
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! |
|
The issue is up here: #4207 |
|
I would like to contribute, but am not sure how much time I would be able to dedicate. Some comments:
|
There's the #mumble-dev channel on IRC |
|
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. |
|
Rust GUI information/libs information https://areweguiyet.com/ |
|
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. |
|
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.
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. |
|
I share both enthusiasm and scepticism for a rewrite, so here are some thoughts applicable to both. My perspective as a (somewhat recent) Mumble userI 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. Backwards compatibilityI 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). 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 audienceDo you plan do give up/break compatibility with Mumble/the Mumble protocol? If you do, then question everything, and don't just reimplement features. MeasureDo 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? ModularizeAFAICS, 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.
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. |
|
hello all |
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.
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.
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... |
|
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.
I agree with that problem, but am not sure if it's applicable.
That means professional environments/companies are part of your target group. (I did not think that was the case.)
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. |
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. |
It actually got fixed very recently. The fixed version will be shipped with 1.4.0 :)
No problem |
|
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: RefactorWe 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. 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. 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. 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 :) |
|
See #4261 for the discussion about how to make sure Mumble's c++ code base will get future-proof ☝️ |
|
They landed on a similar incremental refactoring approach, but with Rust:
|
Given the current state of the codebase, it might be a good idea to just go and rewrite Mumble from scratch in order to get a modern codebase that is then hopefully easier to maintain, more transparent and most importantly: more accessible to new devs.
I'd like to use this issue as a platform for discussions as to how this would be tackled best, what should be looked out for (aka "best practices") and also (and this one is important) are there people out there that might be able (and willing) to help us accomplish this? The big advantage here would be that no previous knowledge of the current Mumble codebase is necessary (though of course it won't hurt), so this might be the ideal point to start contributing to the project to help us making Mumble future-proof :)
Summary
(I'll try to extract the main points from the discussion and add them here so that we'll have a nice overview of the results)
Potential contributors
(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)
@davidebeatrici, @Krzmbrzl, @felix91gr, @Avatat, @jplatte, @jairomer, @TredwellGit @Kissaki
The text was updated successfully, but these errors were encountered: