[mpris] working on a 2.0 draft

[Mirsal Ennaime]

On Sun, Jun 13, 2010 at 6:57 PM, Ian Monroe <ian at monroe.nu> wrote:
> On Sun, Jun 13, 2010 at 5:56 AM, Alex Merry <kde at randomguy3.me.uk> wrote:
>> 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.

I think that the client-side scaling issue should be tackled by
allowing clients to only fetch a subset the tracklist, though this can
be done in a later revision of the spec.

You already took the first steps in the right direction with the new
tracklist signals.

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

Yes, obviously :)
I wrote this part of my e-mail a bit too fast.

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

No, I think that the track id can stay the same in that case.

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

media players are not required to expose their entire playlist, so at
first, you can address the media player-side scaling issues by only
exposing the first few tracks over dbus.

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

Yes, definitely.

media players which do not implement the tracklist modification stuff
can still use positions in the tracklist as ids and emit a
TrackListReplaced signal whenever something changes

This behavior would be very close to how things are done in 1.0 thus
making it quite easy to port existing implementations to the new spec.

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

I agree, however I do consider adding and removing tracks as basic
playlist handling (for players with which it makes sense)

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

As track ids would be used solely to identify items within the track
list, I believe we should not enforce anything more than uniqueness in
the scope of the tracklist.

>> Although, as I said before, I think we should provide a way for
>> implementations to refuse to deal with such a request - a capabilities flag
>> and/or a "succeeded" return value. [...]
>> A capabilities flag would allow an implementation to tell clients that it will
>> never accept new tracks (the Spotify case) and a return value would allow
>> implementations to say that it is refusing that particular URL (maybe it can't
>> find the file, or doesn't understand the format).

We do need a capability flag for tracklist modification stuff, but we
should use dbus's error reporting mechanism instead of adding a return
value to AddTrack


cheers
-- 
Mirsal