(Last-Updated: 2016-07-14 by mkrautz)
The problem with adding new permissions, is that older clients don't understand them.
This shouldn't be too much of a problem, because the permission system is an "administration-only" feature. That means we can a little less strict about backwards compatibility because the vast majority of users will still be able to use their older clients without problem.
However, in practice, there are some pitfalls. This document tries to address those.
By adding permissions and changing existing ones, we can't have older clients administer Murmur instances that use the newer permission system.
So we would have to lock out people from changing ACLs on those servers if they use an outdated client.
There are two cases to handle:
First, adding a new channel. This doesn't require a roundtrip to the server, until the add operation is submitted. We should reject them once the client tries to add it.
Second, changing an existing channel. This can be caught early, because the ACLEditor is shown when msgACL is received. Instead of showing the ACLEditor, Murmur should reject the client if it is not new enough to understand the server's ACLs.
Mumble clients use a protobuf message, PermissionQuery, to query for permissions in order to improvde the user experience.
For example, if a PermissionQuery is returned that says a user doens't have permission to edit a channel, the Edit context menu action will be disabled (grayed out).
This is a problem if we change the permission system.
To fix this in a general way, I think we can simply change Murmur to discard received PermissionQuery messages from older clients. If we do that, older clients will show all context actions as being available -- but once they're used, they will fail.