[mpris] working on a 2.0 draft

[Alex Merry]

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

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

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.  I can think of several possibilities for 
why a player might not want to play an arbitrary URL, even though it allows 
playlist manipulation.  Think of a media player that is exposing its D-Bus 
interface on a different machine on a network, say (D-Bus over TCP/IP, 
anyone?), or a Spotify-like client that makes exclusive use of an online 
library.

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

Note that such a capabilities flag should be distinct from the concept of 
adding tracks from some possible future "library" mpris interface.

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

Yes, definitely.

> Also, I think Identity and MprisVersion should be properties instead of
> methods.

If we're changing the interface names (to org.mpris.foo), we should be able to 
happily do this without interfering with clients expecting to interact with 
MPRIS v.1-style services.

I should put my interfaces on Gitorious and add in these changes as we're 
discussing them, I think.  I'll try and do that this week.

Alex



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.videolan.org/pipermail/mpris/attachments/20100613/3956c1be/attachment.pgp>