<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta name="generator" content="Osso Notes">
    <title></title></head>
<body>
<p>----- Original message -----
<br>&gt; Hi folks,
<br>&gt; 
<br>&gt; Way back Alex proposed an extension to the spec to handle Playlists. 
<br>&gt; There didn't seem like there was too much interest at the time, 
<br>&gt; apologies for my silence I had a Maverick release to attend to.
<br>&gt; So how about now, I think there are some clients which are interested. 
<br>&gt; The extension can be found here.
<br>&gt; 
<br>&gt; <a href="http://www.randomguy3.me.uk/mpris/Playlists.html">http://www.randomguy3.me.uk/mpris/Playlists.html</a>
<br>&gt; 
<br>&gt; Conor
<br>&gt; 
<br>&gt; -- 
<br>&gt; Sound Architect
<br>&gt; Desktop Experience Team
<br>&gt; Product Strategy
<br>&gt; Canonical
<br>
<br>The Url type is defined and not used (I think).
<br>
<br>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?
<br>
<br>Perhaps the type of the playlist should be revealed? I could imagine a applet using an icon to indicate it.
<br>
<br>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.
<br>
<br>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.
<br>
<br>Ian</p>
</body>
</html>