[mpris] MPRIS misdesigns

[Mirsal Ennaime]

On Wed, Feb 11, 2009 at 9:28 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> Heya!

Hello and sorry for the late answer.

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

That would be really nice.

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

Yes, I'm aware of that and I planned to change this in MPRIS 2.
Unfortunately I ran out of spare time, and many issues like this one
are still part of the api.

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

This not a use case we thought about, the spec needs to be changed in
order to allow stuff like that.
Anyway as there are many design mistakes, the API must be redesigned.
Noone in the original team were experienced in D-Bus APIs design when
we wrote it which caused the project to stall. So if someone with the
required knowledge could do something about it, it would be really
helpful.

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

I read your blog post on Planet GNOME, but I lack time and experience
to fix all of these issues.

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

I'd also like to see some people who actually know about D-Bus API
design to show interest in the idea so something can be done about it.

Regards,
-- 
Mirsal Ennaime