[mpris] working on a 2.0 draft

[Mirsal Ennaime]

Hi,

On Sat, Jun 12, 2010 at 9:41 PM, Ian Monroe <ian at monroe.nu> wrote:
> On Sat, Jun 12, 2010 at 1:20 PM, Alex Merry <kde at randomguy3.me.uk> wrote:
>> I was right in the middle of working out a potential 2.0 version of the spec
>> (although my changes were a lot more invasive) when I came across this.

This is great !

>> The major problems I would like to see addressed:
>>
>> * Incorrect use of D-Bus interfaces - the different objects should be different
>> interfaces, although they could still be on well-defined objects

Yes, however I'm not sure that the org.freedesktop prefix can be used
for interface names in non fd.o-approved specs, so I would rather go
for org.mpris instead.
Please correct me if I'm wrong, the only useful info I have found on
this is this thread on the xdg mailing list:
http://lists.freedesktop.org/archives/xdg/2009-July/010757.html

>> * race conditions and ambiguity in the playback/pause state - Pause acts as a
>> Play/Pause toggle, which means that a client can't reliably ask the player to
>> enter pause mode unconditionally
>
> This is really important.

I agree.

>> * The only way to implement a useful position slider for the track is
>> currently to regularly call GetPosition, which is wasteful of resources.  More
>> sensible would be to implement the GetRate method suggested by Jean-Paul
>> Saman, and a signal to indicate when seeking has happened

Yes.

I would also add a capability flag indicating whether the position
information is available.

>> * TrackList is inherently racy in many ways.  Use the modification methods is
>> perilous, particularly if the media player has something akin to Amarok's
>> dynamic playlists, where tracks will be regularly removed from the beginning
>> of the track list.
>
> Arguably track list modification is out of scope for MPRIS. I guess
> you agree since you took it out I believe?

I disagree about removing these methods, the races should be fixed instead:

* the Position property should be replaced with a CurrentTrack one
which would contain the current track id
* the PositionChanged signal should be replaced by a CurrentTrackChanged signal
* the TrackAdded, TrackRemoved and TrackMetadataChanged signals should
use the track id instead of its position in the tracklist (it doesn't
really matter for TrackListReplaced since it is atomic but it should
reflect this change for the sake of consistency)

* AddTrack:

        <!--
        Adds an track to the track list.

        The first argument is the uri of the track to add

        The second argument is the track after which the new one
should be inserted.
        If it is an empty string, the new track will be inserted at
the top of the track list.

        The third argument is whether the newly inserted track should
be considered as
        the current track. This has the same effect as a call to GoTo
afterwards.
        (see GoTo below)
        -->
        <method name="AddTrack">
            <arg name="Uri" type="s" direction="in" />
            <arg name="AfterTrack" type="s" direction="in" />
            <arg name="SetAsCurrent" type="b" direction="in" />
        </method>

* DelTrack should take a track id as an argument.

We should also clearly define the track ids as unique in the scope of
the track list (that means that if a track is present multiple times
in the track list, each entry must have a different id.

Removing the possibility for a client to tell the media player to play
a new track would be a mistake IMO

We should also add this method:

        <!--
        Skip to the track id specified as argument.

        If the playback is paused or stopped, it remains that way.
        -->
        <method name="GoTo">
            <arg name="Track" type="s" direction="in" />
        </method>

>> Besides that, if we want to keep the traffic for this mailing list at its
>> traditional low level, we probably want somewhere else to do this discussion.
>> http://xmms2.org/wiki/Talk:Media_Player_Interfaces is a possibility, although
>> maybe an IRC channel might be a good idea?

There is #mpris on freenode. I'm usually there with Conor Curran.

> There's no reason we need to preserve the low-traffic status.

Well, this is important stuff so I think this discussion should happen
here anyway.

>> For anyone interested in what I came up with, the files (without the telepathy
>> docs) are at http://www.randomguy3.me.uk/mpris/.  The changes are probably too
>> drastic for most people's tastes, but there might be some ideas to be had from
>> there.

I do think that problems should be solved and doing so sometimes
requires drastic changes ;)

> What's the point of GetPlayerObject? If there's a standard naming
> scheme this isn't needed.

Seconded: While I see the need for GetTrackListObject, this one has no
point being defined if we rely on well-known object paths, which I'd
like to stay that way as not doing so holds no significant advantage,
and requires additional dbus round trips.
Also, I think Identity and MprisVersion should be properties instead of methods.



Thanks for your work, Alex, this is awesome !
cheers,

-- 
Mirsal