[mpris] working on a 2.0 draft

[Ian Monroe]

On Sun, Jun 13, 2010 at 5:56 AM, Alex Merry <kde at randomguy3.me.uk> wrote:
> On Sunday 13 June 2010 03:23:33 Mirsal Ennaime wrote:
>> 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:
>> >> 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.
>
> I think you're right - we should use org.mpris prefixes instead.
>
> Incidentally, changing the interface names would allow MPRIS 1 and MPRIS 2
> interfaces to co-exist.
>
>> >> * 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.
>
> Good idea.
>
>>
>> >> * 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
>
> I briefly toyed with a CurrentTrack property, actually, but wanted to keep the
> Position one as well for efficiency on the client's side - some people like to
> have playlists with 10000 tracks in.  Although I suppose that if they do, they
> should expect some slowness.
>
>> * 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)
>
> TrackAdded needs to allow the client to place the new track in the correct
> position in the playlist.  So, at the very least, it would need to say what
> track it was after (this would naturally be empty for the start of the
> playlist).
>
>> 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.
>
> I was originally thinking that they could be uris for the tracks, but if we
> want to completely replace position markers with them, then they would indeed
> have to be unique in the tracklist (what if a track is removed then added
> again, incidentally?  Does it have to change?).
>
> This, of course, is likely to complicate TrackList implementations in media
> players - I would guess that, internally, most media players effectively just
> keep an ordered list of tracks.  Certainly, I would have to think very
> carefully about how to implement this in Amarok efficiently (we really do have
> people who dump their entire collection into the playlist, then complain when
> it's slow).

I think we do really need to think about ease of implementation.

Plus MPRIS should be only for really basic playlist handling. I think
its impossible to avoid player-specific API for full playlist handling
since each player does things differently and has other features that
would need to be revealed to be a true playlist controller (eg dynamic
playlist toggling for Amarok)

So in Amarok we have no straightforward way to create a unique track
id, that would be unique even if the same track was in the list
multiple times. I think this is a corner case we just shouldn't handle
100% correctly. I think using URI's to specify tracks makes the most
sense, since having URI's for tracks is what Amarok does and probably
plenty of other players.

If a music player did want to have these URIs be 100% unique they
probably could elect to encode some extra info into the URI and make
that happen.

Ian