Re: [Rhythmbox-devel] Central plugin repository

[Alex Lancaster <alexl users sourceforge net>]

>>>>> "FL" == Federico \"Lox\" Lucignano  writes:

>> I also think that time might be better spent trying to get the
>> plugins into SVN trunk.  So please file enhancement bugs in
>> bugzilla.gnome.org for any third-party plugins that don't already
>> have one.  If you create the plugin as a patch against SVN trunk,
>> your chances of getting into SVN are much greater than just
>> attaching a tarball that isn't integrated into the build system.

FL> Some plug-ins will never make for SVN due to many factors,
FL> e.g. they could be developed to address a specific problem of a
FL> certain user (it's my case, just look at the plug-in I've released
FL> recently on this list) or as an improvement/alternative to an
FL> existing plug-in, they could be not as finished as required for
FL> being released officially whith Rythmbox and so on.

I'm not arguing that third-party plugins aren't useful or necessary in
some cases.  I'm just saying that there are many plugins that could
usefully live in rhythmbox upstream SVN that with just a bit more
work.  e.g. the alarm clock plugin, the lastrhythm plugin.

The problem with third-party plugins is that 1) they can be difficult
to find for users and 2) don't integrate well with the native package
manangement tool.  Having them in SVN means that plugins get wider
testing; they are more likely to stay in sync with the core code; they
get l10n attention; and potential problems with plugins interfering
with each other are much easier to spot.

Again, that said, having a place for third-party plugins is fine, and
I realise that not all plugins will reach the standard where they can
be included in SVN.  So if people want to create a place for them,
that's fine too.  I also realize that Launchpad isn't purely Ubuntu
specific (my issue with Launchpad is that the code for Launchpad
itself isn't open-source [this is also an issue with
SourceForge.net]).

FL> Just take a look at the list of available plug-ins/script for
FL> Amarok released through KDE's extension manager (
FL> http://www.kde-apps.org/index.php?xcontentmode=56 ), how many of
FL> those ones would be released officially with Amarok? Almost none,
FL> since Amarok's devs know that users will be able to get any script
FL> available on kde-apps through Amarok itself and plug-in developers
FL> know that they have to publish their creations on kde-apps if they
FL> want to share them.  The same applies to Firefox/Thunderbird and
FL> Opera (widgets) just to name a f

This is slightly off-topic but point 2) is important when you want to
deploy plugins system-wide, e.g. installing a plugin on my system
(through rpm/yum or dkpg/apt-get) for all users obviates the need for
each user installing the identical code in each of their directories.

Although this is hard problem in general, I would like to see more
third-party plugins systems, such as Firefox, OpenOffice.org
etc. making a better effort to think about how plugins could interact
with native package management systems rather than re-inventing an
"plugin/extension managers" for every new application.

FL> The "rush to SVN" is for adding new features to Rhythmbox through
FL> a native implementation, not for plug-ins, there would be no point
FL> in making available a plug-in system if users should wait for the
FL> next big release of an app to use them. ;)

Not so, most of the plugins in SVN rhythmbox are in Python, not in C.
The plugin system also has uses besides allowing per-user third-party
plugins (although that is obviously an advantage), e.g. distros can
package each of the plugins in a separate subpackage
(e.g. rhythmbox-daap, rhythmbox-lastfm) , to reduce runtime
dependencies for the core rhythmbox app, as is done with gstreamer.

Alex