[mpris] MPRIS misdesigns

[Ian Monroe]

On Wed, Feb 11, 2009 at 3:37 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 11.02.09 15:08, Ian Monroe (ian.monroe at gmail.com) wrote:
>
>> > 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?
>
> Dude, the way to fix this is obvious. Add a SetPauseState(bool b) call
> and everything is fine. The pause state is then set to the boolean
> passed, the previous pause state is irrelevant.
>
> Now, don't tell me you weren't able to come up with a fix for this yourself.
>
>> > - 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?
>
> Ah, so you had a clown for breakfast today?
>
> Lemme check. Ah yes, there at the 5334th spot on my TODO list I found
> a free spot. Let's add a new item there: "Rework MPRIS and update all
> gazillion of Linux media players for it accordingly".

Who said anything about reworking a gazillion media players? Of course
that points out the futility of complaining about an API that can't
easily be changed, at least futile as far as the short term is
concerned. But apparently your fixes are "obvious", just put them
together on the wiki and we can work out a MPRIS 2.0 perhaps.

Ian