[mpris] [RFC] MPRIS2 Release Candidate

[Alex Merry]

  On 07/08/10 19:20, Lennart Poettering wrote:
> - please use the recently standardized property change signals when
>    properties change. Don't cook your own signals.

There's a recent standard for property change signals?  I can't find it 
with a cursory search of the web (or the D-Bus site), but I'm not really 
sure what I'm looking for.  Could you point us to it?

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

That's probably reasonable.  It's a pity that Qt doesn't support 
retrieving all properties at once.

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

Capabilities simply indicate what is possible _at this moment_.  For 
example, it is not possible to go to the next track if there is no next 
track.  It allows clients to present a disabled interface element, for 
example.

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

Well, versioning is entirely orthogonal to capabilities.

I think that using interfaces for the "major" versions is certainly a 
good idea.  We've already demonstrated that the major version field 
isn't very useful.

I'm undecided about the minor one.  On the one hand, the UnknownMethod 
error should be sufficient, but it's potentially useful to clients to 
know in advance what to expect (they might offer a slightly different 
interface depending on the version implemented, for example).

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

Do you have a suggestion for a sane way of doing this?

> - Why is there no signal that notifies about added/removed playlists?

Good question.  The VLC guys will have to talk about that, though - I 
haven't really been involved with that side of the spec.

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

Everything in your music collection?  The tracklist is just what is in 
the current tracklist, or in a particular playlist.  And we don't even 
require that the server exposes the _entire_ tracklist.

The only part of the data you can't split up into multiple calls is the 
list of track ids, anyway.  The metadata comes from a separate call, and 
you can ask for any subset of the tracklist you like.

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

I don't think we need to require that.  There's no particular use for 
it.  If implementations want to do that, they can, but I don't see why 
we should constrain them in that regard.

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

Well, in a way, it's whatever scale the implementation considers 
sensible.  The user will expect a slider control for the volume in the 
client to behave in the same way as the volume control provided by the 
media app itself, so that's how it should work.  0.0 is minimum, 1.0 is 
maximum, what happens in between should be "sensible".

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

microseconds?  This is for music players, not real-time audio editing.  
Given the latencies involved in sending messages over D-Bus and what 
humans can generally deal with, even milliseconds is probably 
overzealous, but it's a nice easy value to deal with that's finer than 
seconds.

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

I think you're probably right here.

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

http://live.gnome.org/Rygel/MediaPlayerSpec

Oh, joy, another media player control spec.  What was MPRIS for again?

We could probably subsume this.  I do wish people would _try_ and work 
to make existing specs fit their needs, rather than just creating their 
own.  I mean, we've tried to make MPRIS easy to implement for the simple 
case, and we would welcome any input to improve that.  I'm going to hope 
that it was just because the people involved weren't aware of MPRIS.

Is http://live.gnome.org/Rygel/MediaServer2Spec the media server spec 
you were referring to?  I can't find the Grilo D-Bus apis, unless that's 
the media player spec I linked to above.

And I thought we were pretty much done with this :-)

Alex