[mpris] [RFC] MPRIS2 Release Candidate

[Ian Monroe]

On Sat, Aug 7, 2010 at 1:20 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Thu, 29.07.10 15:29, Mirsal Ennaime (mirsal.ennaime at gmail.com) wrote:
>
>> Hello,
>>
>> I would like to propose this document as a mpris 2.0 release candidate:
>>
>> http://www.mpris.org/mirsal/2.0-draft/spec.html
>>
>> Could you have a look at it and share any remark, concern, improvement
>> proposal you have in mind ?
>
> A few comments:
>
> - please use the recently standardized property change signals when
>  properties change. Don't cook your own signals.
>
> - i am not a particular fan of using integers for bit flag fields/enums
>  on D-Bus. I think it is usually much nicer to use strings for
>  enums. And bitfields should probably be just seperate bool
>  properties. modern bindings such as gdbus optimize this nicely and
>  retrieve all flags with a single call.

Bit flag fields seem more straightforward to me for capabilities.

> - It makes little sense to me that "capabilities" might change. What's
>  the rationale? CapabilitiesChanged is redundant I believe.

Some tracks can seek, some can't, start and end of the playlist.

> - simplify the version stuff. One version counter should be more than
>  sufficient. There is no need for major+minor. Also, why do you need
>  both the version stuff ad the capabilities stuff? choose one. Finally,
>  I think versioning should be done via interface names and
>  suchlike. See http://0pointer.de/blog/projects/versioning-dbus.html

Major is for breaking old clients, minor is for adding new features to
the API. Why is dbus so much more different then a normal library
versioning?

> - i wonder how scalabale the playlist stuff is. i.e. does it always make
>  sense to send the list of playlist in a single msg? If there's a
>  substantial amount of playlists (and there might very likely be as
>  most music on the internet ship with an .m3u or .pls file). I think
>  this needs some logic to allow splitting up requests and responses
>  into chunks, so that multiple small messages may be sent instead of a
>  single big one.
>
> - Why is there no signal that notifies about added/removed playlists?
>
> - The tracks stuff is definitely not scalable. You definitely don't want
>  to send the the track info for everything in my music collection in a
>  single message. It's gigantic and the bus would even refuse delivering
>  messages as big as that. requesting the track list must be doable in
>  chunks.

This isn't meant to be a collection api. Your solution isn't a bad
idea though. I  just worry about the API getting too complex.

> - i think the track id should be a dbus object path. That's how we
>  identify objects in dbus. this wouldn't even have to mean that you
>  expose any interfaces for these objects...

What is the advantage to this? Having the trackid be whatever internal
representation that is meaningful and easy to use for the audio app
makes sense to me.

> - what unit is the value for AdjustVolume in? dB? linear? probably
>  neither? given that for many audio devices the volume scale is unknown
>  it is probably not smart using dB/linear here. Hence you should probably say that 0.0 is
>  silence and 1.0 is a "sensible maximum volume", but you probably
>  should allow the volume to go beyond 1.0. and everything in between
>  should be in a scale that "feels right" to the user.

Yes, agreed. We already discussed that double makes more sense for volume.

> - If you pass times use 64bit integers and use usec as unit. That's what
>  most media systems do these days and i think is a the only unit that
>  makes remotely sense.

Yea, its what Amarok uses.

> - the player state shouldn't be a struct. Just seperate bool props.

They aren't all bool, but yea I agree splitting that up would make
things easier.

> Also, I wonder how this actually relates to the grilo dbus apis? also,
> the mediaserver dbus spec seems similar a bit too (if only for the track list
> part). There might be a good opportunity to reuse existing interfaces or
> at least make the interfaces feel similar in style.

I wasn't familiar with either of those. Could you link to their DBus
APIs? Google is failing me with the too-generic mediaserver and
Grilo's page doesn't make it obvious where the spec is. I see it
mention Rygel, so it is a system for sharing collections as opposed to
controlling a running playlist. Maybe MPRIS should drop its ability to
handle multiple playlists since thats getting quite collection-esque.
(Or whats the use case exactly?)

Ian