[mpris] Playlist extension observations

Alex Merry kde at randomguy3.me.uk
Fri Dec 10 20:30:58 CET 2010


On Friday 10 December 2010 13:19:39 Ian Monroe wrote:
> You are correct of course, but we can still talk about sync and async
> D-Bus apis. If it takes a really long time for a function to return,
> it can time-out and such. So if that's a possibility you'd want to
> have a "async" api with a request method and a signal to give the
> results.
> 
> I don't really see that being an issue here, though its something to
> think about.

Depending on what you're trying to acheive, that's somewhat dirty and racy 
with D-Bus, though, given that signals are potentially transmitted to many 
clients.

Of course, there are situations where this is exactly the right approach to 
take.  ActivatePlaylist (with a CurrentPlaylist property and a changed signal) 
is one of those: it returns nothing (inherently async), and it results in a 
signal being emitted when it succeeds in changing some (global) state.

Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.videolan.org/pipermail/mpris/attachments/20101210/92b68325/attachment.pgp>


More information about the mpris mailing list