[mpris] Playlist extension observations

Conor Curran conor.curran at canonical.com
Fri Dec 10 18:18:42 CET 2010


Hi Ian,


On 10/12/10 15:40, Ian Monroe wrote:
> On Fri, Dec 10, 2010 at 09:35, Conor Curran 
> <conor.curran at canonical.com <mailto:conor.curran at canonical.com>> wrote:
>
>     Hey folks,
>
>     Following what was previously suggested, Bertrand and I  have
>     implemented the proposed playlist extension. Here are a list of
>     modifications which I think are necessary inorder to make this
>     production ready.
>
>         * GetPlaylists should allow for it to be called in an async
>           manner. This can be achieved by passing in a pointer to a
>           PlaylistDetails[]  ( PlaylistDetails being a struct of
>           ObjectPath, string (name) and string (icon path)). Or we
>           could add  a new callback ?
>
>
>
> Callback makes sense to me.

Good to hear.

>        *
>
>
>         * A new method GetCurrentPlaylist ( also accommodating async
>           usage ) should be added. This would be useful for clients
>           that come up and down and hence need to query the server
>           (media player) when starting up to sync properly. If there
>           is no active playlist, it should return a PlaylistDetail
>           with each member set to null ?
>         * A new signal to inform that the current active playlist has
>           changed.
>               o This could also cover the situation where the playlist
>                 has ended and no other playlist has begun in which
>                 case the returned playlist details struct should
>                 contain null members.
>
>     Thoughts ?
>
>
> Perhaps we should only support async and drop all the sync methods if 
> async is needed.
>
> I'm wonder why async is needed though? Most players would have that 
> information on-hand since they have a list of playlists somewhere.
>

I would prefer to call things asynchronously just in case anything blocks.
It should be fine synchronously but I would rather use a more fool proof 
approach.

Conor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/mpris/attachments/20101210/e0f187e0/attachment.html>


More information about the mpris mailing list