[mpris] MPRIS misdesigns

Lennart Poettering lennart at poettering.net
Wed Feb 11 21:28:38 CET 2009


Heya!

In PulseAudio we'd like to add some logic that would allow automatic
pausing of music/movie streams when a voip call comes in. I am now
considering forwarding those pause requests to the applications via
MPRIS. However after having a rough look over MPRIS I have some issues
with the API design:

- The Pause() API is broken by design: there is no way to reliably
pause a stream without knowing the previous state of the stream in
advance. This can be queried via GetStatus but it is inherently racy to
do so the pause status might have changed already until we can call
Pause(). Now you might say this is a tiny race. Unfortunately it is a
real problem for me: e.g. Gstreamer-based media players will get the
pause request inline anyway, hence if they pause due to an inline request
that might interfere with the MPRIS logic we would provide as fallback
for non-Gstreamer media players. The API design is full of races like
this, but this one is actually a problem for the use case I am
interested in.

- There is no way for PA to map a specific application stream to a
media player instance on the bus. It would be good if at least the
process name/PID of an MPRIS service could be queried so that we can
reliably map streams to player instances. Or may I assume that the
service name suffix as in "org.mpris.foobar" actually is the process
name? I assume I may not, given that that is not documented.

- The versioning is broken. Doing this with a call MprisVersion() is
just broken and not realistically implementable. Proper versioning on D-Bus
is done as described here:

http://0pointer.de/blog/projects/versioning-dbus

- Using '/' is as entry point object path is a really bad design
decision since it makes it very difficult to implement MPRIS on a
media player that also implements a different D-Bus interface. (For an
explanation see the same blog story above)

- Using object paths for simple namespacing is a misuse of object
paths.

Hmm, is anyone actually still working on MPRIS? The ML seems kind-of
dead according to the archives. I think the idea of MPRIS is a good
one. However the current interface has too many shortcomings to
actually be useful except for the most trivial cases. Hence, I'd love
if someone would beef up this spec and make sure it gets updated in
the various players.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4


More information about the mpris mailing list