[Rhythmbox-devel] Re: ANN: RhythmboxLIRC -- a program to control Rhythmbox with a remote control



On Fri, 01 Jul 2005 15:02:35 +1000, Jonathan Matthew wrote:
> I am planning to do this, but maybe only through D-BUS, rather than both
> D-BUS and CORBA.  I can see a point in providing both remote interfaces
> at the current level of functionality, but going much further (exposing
> playlists, rhythmdb queries, and so on) with both interfaces is probably
> going to be too much work.

Both are fine with me--as long as there are Python bindings I'm happy. :-)
 
> Does anyone have any clever ideas on how to make rhythmbox spawn
> processes like this one, without tying it to either bonobo-activation or
> D-BUS?  If the remote interface is rich enough, this would make a decent
> alternative to a traditional plugin system, with better crash
> resistance.

RhythmboxLIRC currently takes the opposite approach. It is a silent
process which I'm starting as a GNOME session startup program. When it
gets a command from the remote, it uses Bonobo Activation to discover an
existing Rhythmbox instance or to spawn a new one if there is none. When
you press the stop key on the remote, Rhythmbox gets a signal to
terminate. When you press play again, a new Rhythmbox instance is spawned.

That strategy seems reasonable for the remote control application, but
it's obviously not suitable for a generic plugin mechanism. But if we want
to have interprocess communication, we need to tie it to _some_ well-known
IPC/discovery mechanism, and CORBA/Bonobo or DBUS seem to be reasonable
choices and I don't really see a need to add yet another
Rhythmbox-specific mechanism to this group.

If you are prepared to sacrifice efficiency for elegance and
extensibility, it might even be worth considering separating the backend
and the frontend into two parts. (Well, maybe for Rhythmbox 2.0 :-) ) If
some discovery method were provided, this would make it possible to have
one media server in the house and have all Rhythmbox instances on all
computers provide access to the same media. The best protocol for that
rather ambitious purpose would, IMHO, be UPnP Media Server/Media Renderer
<URL:http://www.upnp.org/>. There are already appliances complying with
this protocol on the market and it seems to have backing from the big
names.

Best,

      Oliver



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]