[mpris] MPRIS misdesigns

[Ian Monroe]

On Wed, Feb 11, 2009 at 2:28 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

Cool.

> 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.

Erm, do you have a suggested solution or just this complaint?

> - 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.

Where someone is someone else I guess?

Ian