search

mumble-voip / grumble

Alternative Mumble server
http://mumble.info/grumble
Other
275 stars 86 forks source link

TODO items / project status #3

Closed ciarand closed 6 years ago

ciarand commented 9 years ago

Hi there,

What's the current status of this project? Abandoned? Feature complete? What would need to happen to make this a server you'd feel comfortable recommending?

slattery commented 9 years ago

+1, I'd like to know the status and/or plans for grumble as well. Thank you!

nicolasFlinois commented 9 years ago

Same here.

Goblinlordx commented 9 years ago

While it does seem like this might be abandon I would like to mention. I was able to compile Grumble with some slight modifications to the source code (Mostly correction of import references). The tests seem to pass and after building the grumble package, it does actually run. That said, I did have to manually create the config directory to get it to run. I also haven't connected to it yet but I will attempt to when I have the time. I will try to test the server out once I have a chance as running doesn't necessarily mean operational. I am very interested in getting this working and building on top of what is here.

I much prefer golang to the c++ used in the original. As far as features this server has, it looks like it supports opus and CELT though testing is still needed (it could be completely broken). Positional data looks like it is still passed about so that function might be operational as well. ACLs seem to be implemented but again testing will be needed. I am thinking I will likely fork this project and dabble with it a bit when I have a chance.

mkrautz commented 9 years ago

Grumble is pretty much feature complete, except for a few "minor" things.

There is no bandwidth limiting, and there is no API to remote control it.

Grumble's persistence layer is very ad-hoc. It uses an append-only file to store delta updates to each server's internal data, and periodically, it syncs a server's full data to disk.

Grumble is currently architected to have all data in memory. That means it's not ideal for use with very very large servers. (And large servers in this context are servers with many registered users, ACLs, etc.).

It is architected this way because it allowed me to write a pure-Go program with very few external dependencies, back 4-5 years ago.

The current thinking is that if registered users are taking up too much of your memory, you should use an external authenticator. But that code isn't written yet. The concept would be equivalent to Murmur's authenticator API via RPC. But a Grumble authenticator would probably be set up more akin to a webhook -- so just a URL in the config file.

Then there's the API problem. You can't currently remote control Grumble. Which can make it hard to use in production. I imagine Grumble will grow an API that it makes available via HTTP. Murmur's API is already quite stateless in many regards, so it shouldn't be too much of a stretch to put a RESTful API in Grumble to do the same job.

Then there's the naming issue. Recently, @bontibon's https://github.com/layeh/gumble has popped up. We should probably figure out how to name these things to avoid confusing users. :-)

If there are any questions, don't hesitate to ask.

Goblinlordx commented 9 years ago

Awesome ^^ excellent info.

mkrautz commented 6 years ago

Closing this, as the project status was moved into the README.