[Geany-Devel] RFC: Proxy plugins

[Matthew Brush]

On 14-05-09 01:18 PM, Thomas Martitz wrote:
> Am 08.05.2014 02:33, schrieb Matthew Brush:
>> Hi Thomas,
>>
>> If the goal is really to enable loading plugins written in other
>> languages, we should take a really extensive look at LibPeas before
>> ruling it out and duplicating it ourselves. It seems especially
>> appropriate since you want to eventually get multi-language support
>> into core, and it provides a small library we can have a hard
>> dependency on that (IIUC) itself has soft-dependencies on all the
>> stuff we don't want to require for Geany (language runtimes,
>> interpreters, etc.).
>>
>> Disclaimer: I'm not a LibPeas expert or even user but from what I've
>> read about it (the docs, tutorials) it sounds like pretty much exactly
>> the end-goal we want for Geany plugins.
>>
>> My $0.02.
>>
>> Cheers,
>> Matthew Brush
>
>
> Right, LibPeas was repeatedly suggested already. However, the first
> reply was always "uhm it would probably require a massive rewrite" which
> is kind of showstopper given how hard it is to get changes into the core.
>
> Anyway, I have still looked into it and came to the conclusion that it's
> not a good fit either way, for several reasons. Please correct me if I'm
> wrong.
>
> a) All API entry points have to be gir-introspectable, .i.e.
> gobjectified. This is probably the massive rewrite that was suggested.
> This also implies massive plugin API/ABI breakage

I think just the "extension points" need to be GObjects, for example, 
say we had a "code completion provider" API where plugins would be able 
to provide better completions for a particular language, we would have a 
"completion provider extension point" (IIUC). Other examples that we 
keep talking about being useful in Geany which would each require 
"tweaking" the existing code in the ways you propose specifically for 
proxy plugins include:

* Completion providers
* Syntax highlighters
* Filetype plugins
* I had 2 or 3 more that escape me right now

> b) It would breaks the plugin API in more ways. For example, plugin
> metadata shall be supplied via an .ini-style file.

It wouldn't have to severely break the API functions (eg. the stuff in 
geanyfunctions.h) but it would most certainly not be compatible with the 
part of the API used for loading/convenience like all the `plugin_*` 
functions.

> c) Plugins need to implement and expose a new gobject in order to be
> even recognized as plugins (PeasEngine recognizes plugins/extensions by
> their GType)
>

This is not only fairly trivial in C but many times more trivial in 
other languages (well at least in Python it's very simple, not sure 
about other languages).

> After that I'd say that LibPeas is perhaps something to be considered
> for new application but not for our existing codebase. I think we want
> something that enables proxy plugins while maintaining API and ABI
> stability.
>

IMO, it wouldn't be a big deal as a "parallel" plugin system/mechanism, 
while just leaving the old one in place for some years as a "legacy C 
plugins API" (most of the API functions are just plain internal Geany 
functions, not so much work to maintain).

Anyway, I don't really care, but I just think we should consider all the 
problems with the current plugin API and when implementing something as 
you're proposing, not just hack on something for the one use-case but 
maybe think about something more extensible/useful in other contexts.

Cheers,
Matthew Brush