[mpris] [RFC] MPRIS2 Release Candidate

[Lennart Poettering]

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.

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

- 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

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

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

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

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

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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.