[mpris] Playlist extension

[Ian Monroe]

On Thu, Nov 4, 2010 at 10:42 AM, Zeeshan Ali (Khattak) <zeenix at gmail.com> wrote:
> On Thu, Nov 4, 2010 at 5:18 PM, Ian Monroe <ian at monroe.nu> wrote:
>> On Thu, Nov 4, 2010 at 10:04 AM, Zeeshan Ali (Khattak) <zeenix at gmail.com> wrote:
>>> Hi,
>>>
>>> On Mon, Nov 1, 2010 at 3:53 PM, Alex Merry <kde at randomguy3.me.uk> wrote:
>>>> On Monday 01 November 2010 15:35:36 Zeeshan Ali wrote:
>>>>>    How about re-using an existing spec for this:
>>>>> http://live.gnome.org/Rygel/MediaServer2Spec . This is already
>>>>> implemented by gnome-dvb-daemon, pulse-audio (stab Lennart for not
>>>>> caring to update to v2), rygel-grilo and rhythmbox. Yes, I know it
>>>>> seems very much UPnP-specific but if you read carefully its really
>>>>> very generic.
>>>>
>>>> It could be used, but it is geared towards exposing a media library, with the
>>>> associated complexity.  For the use cases we have in mind (geared around
>>>> showing a short "example" list of playlists that can be played, and optionally
>>>> all the playlsits), it is complete overkill.
>>>
>>>  Sorry but that is not true. This spec was originally created by
>>> Lennart for exposing PulseAudio streams on UPnP network. There are
>>> only 2 containers he exposed and each container usually had < 2 items
>>> in them. Most of the metadata in the spec is optional so you can have
>>> a very simple/slim implementation if that is your need.
>>>
>>>> There is also the issue of dynamic playlists, for example, which (in Amarok,
>>>> at least) don't even have tracks until you start playing them.
>>>
>>>  Nothing in D-Bus specs stops you from creating D-Bus objects
>>> on-demand. Also, you don't need to tie-up the life-cycle of the
>>> playlist and its associated D-Bus object.
>>>
>>>>  Representing
>>>> them as a MediaContainer2 would be odd.
>>>
>>>  I don't know the internals of Amarok to say anything about that so I
>>> believe you but IMHO some odd code in one media player would still be
>>> better than re-inventing the wheel.
>>
>> Ok you make a good point. If we can use this API to just show a list
>> of playlists without items, then it could be used.
>
>   You could use it for that purpose, yes! But whats the use-case?

Well you might not know the contents of a dynamic/online/smart
playlists before you start playing it.

[sniped your suggestion, it makes sense to me]

Ian