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

Wed Dec 6 05:04:35 UTC 2006

Allright as i've read on the transcript, you're going to implement the DBus
interace as a "client" anyway.

So for one: nevermind the part about "DBus or nothing", but then again what
is your concern with running one player, and debugging XMMS2 the same time?
Milosz

On 12/6/06, Milosz Derezynski <internalerror at gmail.com> wrote:
>
> Sham:
> Yeah it would basically mean that one player can run at a time, but going
> with what Diego said earlier, i'd concur that it could be very well
> something that is not directly at the core of the application, and it can be
> started without exposing itself through DBus. BMPx can do this in fact if
> you start it with the -bin binary and pass --no-remote to it.
>
> (For those unfamiliar with what i mean with -bin binary: BMPx implements a
> single-application-instance/application-as-service [1] mechanism using DBus
> activation. There is a 'remote' binary which is for all intents and purposes
> for the user just like the main application binary, and a "-bin" binary
> (similar to firefox-bin for firefox/comparable) in libexec)
>
> Furthermore, and i'm aware i might be digging up probably unpleasant stuff
> i see the problem with XMMS2+DBus the one that there is no "real" reason for
> XMMS2 to not switch to DBus (yeah i know about tru's technical explanations
> and the don't-broadcast and no TCP/IP transport stuff but that will appear,
> well anyway back to the main sentence), so, basically, once XMMS2 implements
> a DBus interface using this common spec, there would be no _real_ reason to
> not to switch to DBus entirely for server<->client messaging (XMMS2 to
> clients for those not in the know).
>
> So either this will happen (you switch entirely), or you guys will just
> not switch to DBus at all; everything else is just unfeasible if not at the
> very least from a maintenance point of view, and it would be obviously also
> hilarious because of other reasons to implement 2 very similar systems of
> which either could replace the other (except that without DBus, there will
> be hardly a common interface implemented.)
>
> I just want to point this out right now and bring it to the surface,
> before we all start a chanty dance around an empty pot.
>
> Everyone:
>
> As for the table, it's something Sham has done some good while ago and
> it's a good starting point to see how common the current interfaces are.
>
> Sham (again):
>
> Can you wiki-fy the table and make it editable (perhaps only on request
> and only for people you approve for, well, namely the media player
> developers or the players listed there at the least, so we can quickly amend
> it, etc.. ?
>
> Regards,
> Milosz
>
> [1] http://live.gnome.org/DesktopAppsAsDBusServices (NOTE: We actually
> deployed this mechanism 1 year before Alex proposed it in his form, so our
> implementation differs in details, but is essentially the same; it doesn't
> go -as- far as putting stuff into .desktop files that could be regarded as
> bogus until really accepted as a spec/way to do things)
>
> On 12/6/06, Sham Chukoury <eleusis at xmms.org> wrote:
> >
> > 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<http://xmms2.xmms.se/%7Eeleusis/misc/client-api-table.html>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20061206/c610576e/attachment.html>