The SVN version of Murmur now has DBus bindings. It's currently sort of a skeleton implementation, but basic querying works. Fetching the channel structure, players connected etc works.
I'd really like some feedback on the interface though (the exported functions). Are they too minimalist, or can people work with this?
(Take a look at MurmurDBus in DBus_real.h in SVN to see the bindings. All the slots and signals there are exported).
At the moment, getting player status is achieved through either getPlayers() or getPlayerState(short id). This will return a struct containing player state (muted, channel, bandwidth etc). To do something to a player, call setPlayerState() with an updated struct. There is no mutePlayer() or movePlayerToChannel(). The reason for this is that there's a massive overhead for each call on DBus, so it's faster to transfer a larger struct on each call than to have several calls to get the same effect.
Again, comments would be very welcome.
Is this a resonable list of commands available?
setTempGroups(const int playerid, Channel cChannel, const QStringList &groups);
getACL(int channel, const QDBusMessage &, QList<ACLInfo> &acls,QList<GroupInfo> &groups, bool &inherit);
setACL(int channel, const QList<ACLInfo> &acls, const QList<GroupInfo> &groups, bool inherit, const QDBusMessage &);
setBans(const QList<BanInfo> &bans, const QDBusMessage &);
kickPlayer(unsigned int session, const QString &reason, const QDBusMessage &);
getPlayerState(unsigned int session, const QDBusMessage &, PlayerInfo &state);
setPlayerState(const PlayerInfo &state, const QDBusMessage &);
setChannelState(const ChannelInfo &state, const QDBusMessage &);
removeChannel(int id, const QDBusMessage &);
addChannel(const QString &name, int parent, const QDBusMessage &, int &newid);
getPlayerNames(const QList<int> &ids, const QDBusMessage &, QStringList &names);
getPlayerIds(const QStringList &names, const QDBusMessage &, QList<int> &ids);
setAuthenticator(const QDBusObjectPath &path, bool reentrant, const QDBusMessage &);
setTemporaryGroups(int channel, int playerid, const QStringList &groups, const QDBusMessage &);
registerPlayer(const QString &name, const QDBusMessage &, int &id);
unregisterPlayer(int id, const QDBusMessage &);
updateRegistration(const RegisteredPlayer &player, const QDBusMessage &);
getRegistration(int id, const QDBusMessage &, RegisteredPlayer &player);
getRegisteredPlayers(const QString &filter, QList<RegisteredPlayer> &players);
verifyPassword(int id, const QString &pw, const QDBusMessage &, bool &ok);
getTexture(int id, const QDBusMessage &, QByteArray &texture);
setTexture(int id, const QByteArray &, const QDBusMessage &);
playerStateChanged(const PlayerInfo &state);
playerConnected(const PlayerInfo &state);
playerDisconnected(const PlayerInfo &state);
channelStateChanged(const ChannelInfo &state);
channelCreated(const ChannelInfo &state);
channelRemoved(const ChannelInfo &state);
start(int server_id, const QDBusMessage &);
stop(int server_id, const QDBusMessage &);
deleteServer(int server_id, const QDBusMessage &);
isBooted(int server_id, bool &booted);
getConf(int server_id, const QString &key, const QDBusMessage &, QString &value);
getAllConf(int server_id, const QDBusMessage &, QMap<QString, QString> &values);
setConf(int server_id, const QString &key, const QString &value, const QDBusMessage &);
setSuperUserPassword(int server_id, const QString &pw, const QDBusMessage &);
D-BUS is working flawlessly though it could be more documented. The path - when I got it right - should be /net/sourceforge/mumble/Murmur.
My mumble server (compiled against HEAD revision) is located at mv.gotdns.org (you can find it in the server browser) and is accessed by a python script which generates a table of players (http://mv.gotdns.org:8080/murmur). Nice thing ;-)
Actually, the path...
Here's the thing. I booted up my Ubuntu 7.04 (gnome) and queried all the attached dbus things on the session bus.
Some were using /full/domain/name/NameOfProgram
Some were using /NameOfProgram
And some were just using /
I went with the second option, but, and here's the thing, the org.freedesktop.dbus interface itself exports directly under "/". Which really tells me I should move to "/". There really is no point in adding a long pathname when there is only ONE exported entry on that object.
What I should do though, is move the registered name from net.sourceforge.mumble to net.sourceforge.mumble.murmur, as those have to be unique, and mumble will probably support basic DBus control (to facilitate the "open URL" commands) and will then grab the net.sf.mumble.mumble
Come to think of it, I think I'll add both of these right now so I don't forget. The first is just "I like it that way", but the second will become a major problem if we don't change it now.
One Problem with the DBus code:
Mac OS X is a Unix variant, but has no DBus.
So the Mac OS X compiler enters all #ifdef Q_OS_UNIX blocks, but has no way of using DBus.
It might be better to use Q_OS_LINUX here or add #ifndef Q_OS_MACX blocks.
murmur.pro has to be modified as well, but that's rather trivial.
On a sidenote: I succeeded in building murmur on Mac OS X (needed just some slight modifications).
I'll try my luck with mumble, but that will be quite difficult, because I have zero knowledge of CoreAudio.
DBus should build natively on MacOSX, you just have to download it separately.
I also found this: http://dbus.darwinports.com/
But since I don't have a mac myself I can't very well vouch for it :(
True - it would possibly build.
But nobody uses dbus on MacOSX (rash statement, but most possibly true).
So there would be no gain for the user and just another dependency.
Maybe making DBus an optional feature would be a good alternative?
Without DBus, there would be no way to use the RPC features of murmur. Meaning no way to use the addon packages like phpBB3 authentication, webpages which show server status and so on. We are not using DBus as a desktop protocol, we're using it as a general RPC protocol, something it does quite nicely. Hence, it doesn't really matter if people use it for other programs or not ;)
Similarily, as soon as they fix QDBusServer, DBus will also be used by the windows port of murmur.
Ok, I didn't know that.
I will build with DBus then. Thanks for the info.
In the dbus wiki I see: /etc/dbus-1/system.d/murmurd.conf needs to be in place, but the tar.gz has the file named murmur.conf
dbus-monitor sees traffic from dbus with the murmur.conf but I'm not sure if this will be an issue later. Should it be murmurd.conf?
The bug is the wiki. It should be murmur.conf.
Though, if you want, you can call it PinkBunniesAreCute.conf, it won't make a difference :)