[Geany-Devel] RFC: Proxy plugins

[Dimitar Zhekov]

On Wed, 07 May 2014 23:58:11 +0200
Thomas Martitz <kugel at rockbox.org> wrote:

> Am 07.05.2014 19:59, schrieb Dimitar Zhekov:
> > On Wed, 07 May 2014 08:40:13 +0200
> > Thomas Martitz <kugel at rockbox.org> wrote:
> >
> >> I'm (as of now) motivated to implement proxy plugins (to my amusement,
> >> until splitwindow2 gets finally reviewed...). Therefore I would like to
> >> receive comments on my proposed concept and APIs (further below).
> >
> > Feasible, but... why? Looks a bit like GTypePlugin to me, with it's
> > proxied "dynamic" classes, and nearly zero implementations.
> >
> 
> I'm not sure what GTypePlugin has to do with it. This isn't about 
> loading new GObject classes dynamically (proxy plugins aren't GObjects). 

It's not directly technically related, of course, just seems smiliar as
a mechanism, and as something without purpose.

> Perhaps you can elaborate a bit?

1. KISS.

2. Most plugins have UI. Loading plugins on demand means that the UI
will change dynamically, which is hardly a reason for celebrate.

3. Why can't one simply mark the plugins (s)he needs statically? If
there are any compatibility or resource usage problems, they should be
fixed in the original code, instead of relying that Geany will work
better by loading a smaller set of plugins on demand.

4. If we need dynamic loading (though I don't know of any reason for
that), why not extend the standard plugin API with criterias, and let
the "plugin enabled" checkbox in the PM dialog have a "half-checked"
position for plugins with criterias? Why proxiyng?

5. How do we choose which sub-plugins of a proxy plugin should be
enabled - a tree structure N levels deep? Obviously, one may not be
satisfied with the activation criterias, and may want specific 
sub-plugins explicitly enabled or disabled.

It seems to me that your idea mixes dynamic loading and proxying. These
are not actually related (except for the fact that the criterias, if
implemented, should be appliable to the sub-plugins, if implemented).

> The basic idea is that proxy plugins initially call a Geany API to 
> register themselves as proxies, providing criterias to select potential 
> plugins (for now, this is only a list of file extensions)

> Geany will match files against these criterias and, on match, call into 
> the plugin for the first time.

What exactly will it match - the extensions from the files in the
current session? So the PM dialog will contain a different list of
plugins each time it's open? And yet different list on startup, since
plugin_init() is before any files are loaded? Perpahs I don't
get your idea at all.

> Then when Geany generates the plugin list (i.e. when the user opens 
> plugin manager (PM) dialog) it'll call a second time into the proxy. 
> This time the purpose is to load the actual plugin, and install 
> plugin-specific init(), configure(), help() and cleanup() hooks.

An what happens if the user simply doesn't open the PM dialog - the
actual (sub-?)plugin is never loaded?..

I'm not against specific proxies - loading the interpreter or runtime
Foo once, instead of a copy for each plugin written in/with Foo, makes
sense. But that seems different from what you described, and the
sub-plugin search and choosing should be done by the master Foo plugin,
using the Foo language and/or runtime. Unless we are trying to build
language bridges for the sake of it, there will hardly be more than two
or three of those plugins.

-- 
E-gards: Jimmy