[mpris] Playlist extension

Ian Monroe ian at monroe.nu
Fri Nov 19 19:35:32 CET 2010


On Fri, Nov 19, 2010 at 11:43 AM, Alex Merry <kde at randomguy3.me.uk> wrote:
> On Friday 19 November 2010 12:49:26 Conor Curran wrote:
>> Good stuff Johannes.
>>
>> I suggest then we try to agree upon the final spec.
>
> There hasn't been much serious objection to the spec (apart from Zeeshan
> suggesting that we co-opt the MediaServer2 spec, and we concluded that that
> spec didn't fit our needs).
>
> Ideally, I'd like to see at least one client and one server implementation
> (just coded up and tested, not necessarily released) to make sure we haven't
> done anything stupid, but after that I'm happy for it to become official.
>
>
>> >  Regardless the spec needs some more "conceptual" defintion of what
>> >  sort of playlist should be returned
>>
>> Obviously we want simple static playlists (of the traditional sort). Do
>> we want to go down dynamic playlist route ?
>
> I would say that a playlist is a named sequence of tracks that a media player
> can be requested to play, with no assumptions about whether that sequence is
> finite or deterministic - after all, we don't provide any way to query the
> tracks.  So dynamic playlists would fall under this heading.
>
> Ian also raised concerns about the ordering enum - particularly ModifiedDate
> and CreationDate, which may not entirely make sense for dynamic playlists.  I
> would suggest leaving this up to the media player to treat as they wish,
> suggesting that "when the properties of the dynamic playlist were changed" is
> a sensible approach for ModifiedDate.

That makes sense to me. As did your suggestion to wait for an
implementation or two before making it official.

This essentially means Canonical should go ahead with their plans,
come back to us after they have something working but before its so
close to the next release that they can't make changes to the API if
needed.

Ian


More information about the mpris mailing list