Fwd: Re: [Rhythmbox-devel] extending Rhythmbox [was Re: usage question]

[Benjamin Otte <in7y118 public uni-hamburg de>]

This should obviously have been gone to the list, too.

Quoting Michael Messmore <lists clearcreeksupport com>:

> I don't think XMMS style plug-ins would be a good thing for Rhythmbox at
> all.  I was using the term "plug-in" very loosely and did not mean
> binary plug-ins ala XMMS or Netscape/Mozilla.  I was thinking more like
> the ability to write Perl scripts for Gaim, or scripts for various IRC
> clients.  I guess bindings would be a better term. 
> 
There's 2x2 types of plugins - script/"real" language plugins and in-
process/IPC plugins. (for all that don't know: IPC is Inter-Process 
communication, meaning you create a seperate application that talks to 
Rhythmbox.) All of those exist for different things:
- real/in-process: GStreamer plugins, Gtk image loaders, Kernel modules
- script/in-process: X-Chat, Abiword, Gnumeric, etc
- real/IPC: Nautilus, from views to thumbnailers, Evolution
- script/IPC: the X-Chat script for Rb

The question when thinking about what plugin system to create, you have to 
think about your target audience. There is not really a big question of wether 
you target scripting or "real" langúages, because bindings can easily take care 
of that most of the time. It's just important when thinking about the target 
audience.
The question of wether to use in-process or IPC is a bigger one though.
1) IPC is slower than in-process. This is especially important if you have lots 
of data to transfer. So IPC seems like a bad idea for doing stuff like an 
equalizer in. You'd have to push the audio stream through the whole IPC twice 
(audio data to the plugin and the data modified by the equailizer back for 
output). Same goes for visualiation.
2) IPC connections may disappear at any time (for example when one app 
crashes). The other app must then be able to nicely clean up from that and not 
have left over junk lying around that might disrupt working with the program. 
Because of this it is hard to implement a stateful connection between IPC tools 
that doesn't suck if one goes away. (Nautilus did suck if an embedded file 
viewer just crashed. Suddenly you just had a grey window.) So you're most of 
the time limited to modifying the global state with IPC mechanisms.
3) It is much saner to do stuff via IPC mechansims, because if one plugin 
crashes, the app just cleans up and continues working. If an in-process plugin 
dies the app (and all unsaved data) dies with it.
4) Designing an IPC interface however is much harder than just loading plugins. 
In the plugin case, you can blame a badly-behaving plugin for a crash, in the 
IPC case your app should never die, no matter how stupid the plugin behaves.

The short answer to get from all this is: If you want to have a really powerful 
access to the inner workings, do it in-process. If you want an easy access, 
even for people who don't know much about programming, use IPC.

> But after some reading and thinking, here's what I see.  Think of each
> time someone suggests "use the bonobo interface" to a feature request. 
> So picture this:  A well documented bonobo interface, not only to player
> functionality like Stop, Play, Next, etc. and information like currently
> playing, etc. but also the ability to read and write to and from
> RhythmDB.  Also, I think it would be very nice to have a UI setting
> where if you put scripts in a directory you have the option to have them
> run when Rhythmbox is running.  This last part is kind of "bonus" and
> maybe a bit too much, but it would make running common scripts
> accessible to normal users.
> 
I think the goal for Rb is to get a good IPC mechanism. The problem why this 
doesn't work is that the current way to do this just plain sucks´is because it 
requires a lot of boring extra work and looks just plain ugly. I mean, I don't 
really wanna know what a POA_GNOME_Rhythmbox__epv is, but it seems it's needed 
for IPC. Rhythmbox already contains all the functions to be useful via IPC, 
it's just that nobody exports them. I can see functions like rhythmdb_entry_get 
right here, but I can't call them via IPC, because apparently noone managed to 
connect this to the POA_GNOME_Rhythmbox__epv thing.

> Really a fair bit of this functionality is currently available, it's
> just not documented well and it doesn't always behave nicely (ie. 
> getting ratings for auto-rated songs returns 2 when Rhythmbox displays
> 3).  I guess I'd suggest that this should be a higher priority.  I'm
> also guessing that the response would be that people need to use it and
> report bugs on it/document it themselves.  Alas, you have pinpointed my
> laziness ;).
> 
Oh, the nice thing about this is that you could easily write automated tests. 
Launch rhythmbox, run your testsuite against it, check if it behaves nicely, 
done. That's one of the good things about IPC: You can write useful tests for 
GUI apps. But you're right, the still need to be written :)

> Oh and to address other things:  compile time flags are not a good way
> to reduce/increase functionality.  Most people just stick with the
> packages their distro gave them.  And the more extreme the suggestion
> that arch supplants any plug-in system is ridiculous.  Shoot, I don't
> think even all the developers have moved to arch yet, let alone the
> "average Rhythmbox user".  It would be pretty silly of us to put so much
> work into such a usable interface, and then say that if they want to use
> or remove XY or Z that they have to fetch this or that arch patchset and
> recompile.  I can just picture the deer-in-headlights look now.  Arch is
> good for creating a place to independently develop a feature, but with
> the intention of later merging back into the main branch. In other
> words, it helps on the developers end, the user doesn't care if we use
> Arch, CVS, or two strings and a can.  They just want to figure out if
> they can do this or if they're stuck with that.
> 
There's another thing on top of this: I don't want to install all Debian 
packages available, just because Rhythmbox comes with lirc support, 
Enlightenment support, XFCE support, etc ad infinitum all turned on by the 
Debian guys because someone might want it. A plugin system makes that much more 
manageable.
And people don't start complaining about all the dependencies.

Benjamin

----- End forwarded message -----