[mpris] MPRIS misdesigns

[Marc-André Lureau]

Hi

On Wed, Feb 11, 2009 at 10: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. However after having a rough look over MPRIS I have some issues
> with the API design:
>

I also have issues, starting from the properties exposed as methods :)
and the int16, not supported by glib (although, it's probably getting
fixed in next-next glib :)

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

GetConnectionUnixProcessID should be enough.

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

Good points! Thanks for this post.

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

Clearly, It should be forbidden to use "/"

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

Very much agree on that too. Objects should be for objects, not interfaces.

> 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 like the idea too, and would like to bring it to a higher standard
level. Although I really think that the intention and the attitude of
people on this standard is good.

thanks,

-- 
Marc-André Lureau