[mpris] MPRIS 2.0 draft proposal

[Mirsal Ennaime]

On Sat, Jul 3, 2010 at 4:58 AM, Johannes Sasongko <sasongko at gmail.com> wrote:
> Hi all,

Hello :)

>> Each media player must request an unique bus name which begins with org.
>> mpris.
>
> I discussed this a bit with Jorge. It's not pretty, but it gets the
> job done when you want clients to be able to select which player to
> talk to; we couldn't come up with a better solution.

While this scheme looks a bit weird, it works really well, we came up with this
after a long and careful discussion back in 2006

> I'd suggest placing it under another namespace, though, perhaps org.mpris.players.

This might be more correct indeed. I thought about doing this, but I
arrived to the conclusion that media player names are very unlikely to
cause conflicts with eventual revisions of the spec which would define
other bus names.

> Another thing that can help simplify the interaction with clients is
> this: in addition to grabbing the player-specific bus name, each
> player also tries to grab a well-known bus name (e.g.
> org.mpris.MediaPlayer). The D-Bus queuing mechanism [1] will take care
> of which player holds the name, and a simple client can just connect
> to this well-known bus name without caring about choosing one
> particular player.

This is how the pre-1.0 spec used to define bus names, and it doesn't
work very well in real life scenarios, without simplifying
significantly the interaction with a media player on the bus. (listing
media players using the current bus name policy is really just a dbus
method call away)

>> org.mpris.MediaPlayer
>
> Should have a method to present / show / activate / bring up the
> actual player. I'll leave you to choose the best name for this.

Yes, this can be very useful, though it should not be mandatory.

>> org.mpris.MediaPlayer.TrackList
>
>> GetTracksMetadata ( as: TrackIds ) → aa{sv}
>
> Should we have a GetAllTracksMetadata method as well? This would cater
> for the common case of startup, rather than requiring the client to
> send in all track IDs.

In order for this to work, media players would be forced to fetch
metadata for the entire tracklist,
which could be problematic for large tracklists, as it would negate
media players' efforts to reduce ressource usage by not fetching all
the metadata (this is the case of VLC, for instance)

> Also, perhaps clients should be allowed to specify which metadata they
> want to accept, to reduce traffic (not that interesting unless we're
> looking at Alex's scenario of pulling up a huge playlist).

I'd go for fetching all the metadata for a subset of the tracklist
rather than fetching a subset of the metadata for all the tracklist
when it comes to tackle the tracklist scaling issues.

>> org.mpris.MediaPlayer.Player
>
>> Repeat ( b: State ) → nothing
>> GetStatus ( ) → (iiii)
>
> These have a few problems:
> 1. repeat_current and endless can be thought of one status, as they
> are mutually exclusive.

Well, they are not mutually exclusive, as repeat implies endless.

> 2. There is currently no way to set the shuffle and endless statuses.

the shuffle status can be set using the Shuffle method on the Player interface
the endless one is either set by Repeat or by Loop

> 3. The Capabilities property should include whether these statuses can
> be set at all. For example, Exaile doesn't support repeat_current,
> while a Last.fm player can't set any of them.

There are PLAYER_CAN_REPEAT and PLAYER_CAN_LOOP but I forgot the
shuffle one, thanks :)

> 4. Naming: Repeat here should be SetRepeatCurrent.

It would be inconsistant with Loop and Shuffle. Do you think they
should be called SetLoop and SetShuffle instead ?

>> Position − i (Time_In_Ms), read-only
>
> There should be an note that--to change the position--the client needs
> to use SetPosition, which works around the issue of race conditions by
> requiring the track ID.

Yes, I thought it was obvious enough not to require a note.

> Next, from http://xmms2.org/wiki/MPRIS_Metadata :
>
>> "time"
>> (uint32) The duration in seconds
>> "mtime"
>> (uint32) The duration in milliseconds
>
> For consistency with Position and SetPosition, I believe this should
> be "length" and always in milliseconds.

You're right, though the metadata guidelines should be specified in a
more formal document.
We shouldn't blindly modify this wiki page as it is still used by v1
implementations.

Thanks a lot for your feedback. I'll add what's missing asap.

-- 
Mirsal