Re: Plugins, modules and extensions

[Bastien Nocera <hadess hadess net>]

On Mon, 2011-05-09 at 17:50 +0200, Giovanni Campagna wrote:
> Il giorno lun, 09/05/2011 alle 17.13 +0200, Florian Müllner ha scritto:
> > On Mon, 2011-05-09 at 15:52 +0200, Giovanni Campagna wrote:
> > > A different issue is then UI. Some time ago it was proposed to introduce
> > > addons.gnome.org, skip the (rpm/deb) packaging completely and just
> > > instruct users to go, download the plugin and install it.
> > > This has the problem that the plugin must be in an installable format
> > > (xpi?), not just a random python/js file to drop in .local/share (or
> > > even worse, an autotools tarball).
> > 
> > I'm not sure we need to take extensions into account which do stuff that
> > requires more than the metadata/js/css files - I'd consider extensions
> > already as warranty-breaking, and even more so if it requires
> > compilation/installation outside
> > ~/.local/share/gnome-shell/extensions/foo.
> > 
> > So I'd imagine something simple as a gzipped tarball with a custom
> > extension (gsx == GNOME Shell extension?) which is distributed on
> > addons.gnome.org - then we can have a dedicated app ("Desktop Extension
> > Manager"?) registered as MIME handler to deal with
> > installation/removal/disabling/... .
> 
> So .gsx (application/vnd.gnome.shell-extension) for the Shell, .gdp
> (application/vnd.gnome.gedit-plugin) for Gedit, .epe
> (application/vnd.gnome.epiphany-extension) for Ephiphany, etc.? How
> would it integrate with, for example, libpeas?
> Or a more generic .plugin.tar.xz, and the .plugin contained in it would
> reference Eog / Rhythmbox?
> What format for the container? .tar.xz, even if the extension is
> different? Or a big compressed xml file bundling metadata and code?
> What about more complex extensions, like libsocialweb providers or gimp
> filters? Should they go through the traditional distro channels?

Yes. I'd argue that there are 2 different cases here, for plugins that
aren't shipped with the application itself.

The first is that the plugin isn't done, and the second is that the
upstream maintainer doesn't want them with his other plugins.

You're also conflating two "types" of plugins repositories. For
epiphany-extensions, eog-plugins, etc. the main goal for the split is
keeping the core code small, and only exists for maintenance purposes.

For gnome-shell's extensions, the problem is different, and you don't
want to have them installed by default.

Finally, the above doesn't seem to take into account plugins written in
compiled languages, which I guess is still a large enough number for
some applications that it would matter.

(and libsocialweb plugins should be handled by distributions, yes).