[mpris] suggested additions to the MPRIS spec

[Rafaël Carré]

Le Wed, 23 Jan 2008 21:00:16 +0100,
"Mirsal ENNAIME" <mirsal.ennaime at gmail.com> a écrit :

> Hi,
> 
> On Jan 23, 2008 4:37 PM, Ian Monroe <ian at monroe.nu> wrote:
> > First off Dragon Player http://dragonplayer.org now implements all
> > of the / and /Player parts of the MPRIS spec. It does not
> > do /TrackList since it has no playlist. Could perhaps we put a note
> > in the spec supporting this subset officially? Mostly just to let
> > client writers know they should check for TrackList existence
> > before assuming its there.
> 
> Actually, some time ago, we agreed on that non tracklist-based media
> players should "emulate" a 1-item tracklist and use capabilities to
> indicate they can't go next/previous and so.
> The spec may lack a CAN_ADD_TRACKS capability or so.

A player such as dragon player can always add tracks, but the question
is whether it will erase the previously loaded track. I propose
CAN_HAVE_TRACKLIST

> However, the discussion is open, and making /TrackList optional is
> also an option.

The only useful method in /TrackList is AddTrack , I suggest /TrackList
and AddTrack be mandatory, and a bit in GetCaps can indicate if the
player holds real tracklist capabilities.

> > I added a 'load' method to /Player. It plays the given URL
> > immediately. For other players, this could be done with a
> > combination of TrackList commands, but it's still handy. Its
> > obviously essential for TrackList-less players. Could this be part
> > of official spec as well?
> 
> The AddTrack method held by /TrackList takes a boolean argument that
> indicates if the player should initiate playback as soon as the track
> is added, so it won't be necessary unless we make /TrackList optional.

+1

> > Talking to funman, he mentioned it would make sense to have in the /
> > root module, a method to return the version of the spec being
> > implemented. For instance the current spec could be version 1.0.
> > With the addition of the load method, that would be 1.1. We would
> > only have a major version change (2.0) when backwards compatibility
> > is broken by removing methods or changing method signatures
> > (probably something we shouldn't ever do). Such a method would be
> > common-sense future-proofing.
> 
> Yes, and beyond being a good idea, it's something necessary. We
> planned to add such a thing as soon as the spec is versionned.

We should add this method now, and for now make it return a string such
as "Why aren't you discussing what's wrong and what's missing in this
document, so we can reach a real version number ?" .

> Regards,
> --
> Mirsal Ennaime
> _______________________________________________
> mpris mailing list
> mpris at videolan.org
> http://mailman.videolan.org/listinfo/mpris


-- 
Rafaël Carré
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/mpris/attachments/20080124/1cb66e0d/attachment.pgp