Re: [Rhythmbox-devel] Proposal for a common D-Bus interface for media players

[Sham Chukoury <eleusis xmms org>]

Hello world.

Seb Ruiz wrote:
> Actually, whilst I was in san francisco, I spoke with the xmms2 folks
> about the same thing. we totally agreed on the necessity for it.

Indeed, this was discussed a bit during a meeting: [1]
(full transcript at [2])

> > I've been working recently of a D-Bus [2] control interface for VLC, 
> > to permit other applications to interact with VLC.
> > This implements basic functions such as:
> >         - playback control (Play/Pause/Next..)
> >         - information on medias (Meta-data/Length)
> >         - playlist editing (Add new elements to play)
> >
> > I've been looking at how other media players already implemented that, 
> > and I thought all their interfaces were highly redundant, and could 
> > benefit of implementing a single, common, shared interface.
> >
> > That would let developers use this interface in their programs, and 
> > let their users decide of which media player they wanna use. All about 
> > FREEDOM.

I've done a bit of work on this, though in the form of a Python library (Chalyx 
- for XMMS2 [3] and MPD [4] clients), not an open spec or interface of any kind. 
You can see the class defining the methods to be used at [5]
It's a bit of a compromise between the interfaces provided by XMMS2 [6] and MPD 
[7] (though biased a bit towards XMMS2). You can see a table comparing the 
interfaces at [8] (Some MPRIS/BMP/BMPx calls are included, but they've never 
been implemented in Chalyx)

> > I've copied this specification on the videolan wiki [6], and modified 
> > it to my needs. I tried to keep it as general as possible. However 
> > this still needs more work, and comments.
> >
> > This is why i'm reaching you, developers of some media players, to 
> > comment what i've done or work with me, until that specification 
> > fulfills your needs, and can be used in a real world.
> >
> > This specification should stay as generic as possible, because media 
> > players that want to make specific methods available with D-Bus can do 
> > it through their specific interface.
> >
> > For example, basic methods would be available on the service 
> > org.freedesktop.MediaPlayer and VLC would make streaming methods 
> > available on the service org.videolan.vlc. So, a basic control applet 
> > for the KDE panel originally written for amarok would be able to 
> > control VLC, and a complex pygtk script would control streaming 
> > features of VLC.

Re: 'The Service' on the DBus-spec page, am I to understand that only one player 
supporting the spec may be running at any one time? That makes sense from the 
point of view that the user might want a single 'default' player to control, but 
what if the user wants 2 such players running at a time? For example, listening 
to music using VLC while debugging XMMS2? ;)

Re: generic interface, does that mean there could be standard interface 
extensions? For example, players with access to a media library could have an 
extended interface 'org.freedesktop.MediaPlayer.Library'.

Cheers.
-S

[1] 
http://wiki.xmms2.xmms.se/index.php/IRC_Meeting/2006-11-27/Minutes#Amarok_and_XMMS2_Collaboration
[2] http://dan.chokola.com/files/xmms2-meeting/2006-11-27/transcript.txt
[3] http://xmms2.xmms.se/epydoc/public/xmmsclient.XMMS-class.html
[4] http://mpd.wikia.com/wiki/MusicPlayerDaemonCommands
[5] http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/service.py
[6] http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/xmms2.py
[7] http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/mpd.py
[8] http://xmms2.xmms.se/~eleusis/misc/client-api-table.html