[mpris] Playlist extension

[Conor Curran]

Hi Ian,

The use-case I have in mind is that a remote control can fetch a list of 
playlists, display them with their respective icons and have the ability 
to start playing one .

 >Perhaps the type of the playlist should be revealed? I could imagine a 
applet using an icon to >indicate it. ...potentially be a dynamic 
playlist or an online service?

Good idea ! I could expand the sound menu spec to differentiate between 
the different types of playlists. Of course as you pointed out the 
ordering aspect would be redundant if it were a online service of some 
type.

So by dynamic playlist what do we mean exactly ?

Conor




On 28/10/10 13:23, Ian Monroe wrote:
>
> ----- Original message -----
> > Hi folks,
> >
> > Way back Alex proposed an extension to the spec to handle Playlists.
> > There didn't seem like there was too much interest at the time,
> > apologies for my silence I had a Maverick release to attend to.
> > So how about now, I think there are some clients which are interested.
> > The extension can be found here.
> >
> > http://www.randomguy3.me.uk/mpris/Playlists.html
> >
> > Conor
> >
> > --
> > Sound Architect
> > Desktop Experience Team
> > Product Strategy
> > Canonical
>
> The Url type is defined and not used (I think).
>
> Which is fine with me. It appears the API does not assume a playlist 
> is a static list of songs to play, but could potentially be a dynamic 
> playlist or an online service?
>
> Perhaps the type of the playlist should be revealed? I could imagine a 
> applet using an icon to indicate it.
>
> I do see some assumption of static-ness in the ordering enum. Last 
> modified wouldn't mean the same thing or even typically be recorded 
> for a dynamic playlist.
>
> Regardless the spec needs some more "conceptual" defintion of what 
> sort of playlist should be returned and the intended use-case to 
> ensure some uniformity between players. The reason this api wasn't 
> included with the rest is that its use-case and concepts aren't as 
> self-evident as the other MPRIS apis.
>
> Ian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/mpris/attachments/20101028/037d2d5f/attachment.htm>