[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