[Geany-Devel] RFC: Proxy plugins

[Matthew Brush]

On 14-05-16 03:03 PM, Thomas Martitz wrote:
> Am 16.05.2014 19:32, schrieb Dimitar Zhekov:
>> On Fri, 16 May 2014 16:59:17 +0200
>> Thomas Martitz <kugel at rockbox.org> wrote:
>>
>>> I have a question regarding libpeas. There doesn't seem to be a public
>>> (nor documented) API to add loaders. From what I can see the current
>>> language support of libpeas is quite poor (only python and seed (that's
>>> JS isnt it?)). Also, they don't seem to very committed to maintaining
>>> their loaders[1].
>>>

It doesn't seem to make much sense to support two JavaScript 
implementations, although I don't know the specifics of this.

>>> I think we want to maintain the ability to add loaders on our own,

With Peas you can, in fact it's designed with this purpose in mind, 
unlike the existing C-only loader.

>>> without depending on a 3rd party project. Especially for potentially

Meh, we depend on lots of 3rd party projects, several directly and many 
indirectly (see `ldd geany`).

Peas seems to be quite popular in the community around our framework/UI 
toolkit and is used by several (if not dozens) of popular applications, 
which also means it's readily available in many popular distros' package 
repositories.

Even if Peas becomes unmaintained/unsupported, we could roll it into our 
own source tree and maintain it like we do ctags and tagmanager and we 
still wouldn't have had to write it ourselves :)

>>> creating a compat-loader for our existing plugins. It doesn't seem

After experimenting with this a bit, I believe it doesn't make much 
sense to make a compatibility layer because a) you still need basically 
the same code as the existing loader code, b) you would have to 
change/refactor/re-write lots of it c) you would still have two distinct 
ways to implement plugin interfaces, d) increases chances of breaking 
the existing loader/plugins and e) intertwining the two loaders would 
probably make it harder in the distant future to just drop one of them.

>>> libpeas readily supports this. Unless I'm missing something.
>> The loaders (except for C) are plugins, and the build-in ones are
>> installed in /usr/lib/libpeas-<version>/loaders/ as .so libraries.
>> For example, peas-plugin-loader-python.c contains:
>>
>> G_MODULE_EXPORT void
>> peas_register_types (PeasObjectModule *module) <-- as a regular plugin
>> {
>>    peas_object_module_register_extension_type (module,
>>      PEAS_TYPE_PLUGIN_LOADER,
>>      PEAS_TYPE_PLUGIN_LOADER_PYTHON);
>> }
>
> I found that too. But this is not public and not documented. It's also
> not installed to /usr/include/libpeas-1.0.
>

Yikes! Free Software not properly documented! :)

> Since we want plugin authors to be able to create loaders we need
> something that's stable and documented.
>

Then why do you want to write our own libpeas into the existing C plugin 
loader? It will (at least for some time) be buggier, and less widely 
tested/used/maintained (ie. only by us), take lots of extra effort, not 
automate the bridge between core and the plugins' language, probably be 
less well-documented, and after all, the end result would most-likely 
provide an inferior experience for non-C plugin authors.

> Best regards.
>
>
>> And for the next probable question, there is no search for .py files,
>> instead the plugin .ini file (foo.plugin) specifies which loader should
>> be used (C if missing).
>
> I think this could be a problem too. Unless we maintain two loaders
> (that would be better avoided) we need to find a way to have libpeas

We wouldn't have to maintain libpeas, it's a separate project with other 
developers maintaining it for us. Eventually in the long distant future 
(eg. Geany 2.0), we could drop the old loader and maintain zero loaders :)

> find (and load) current plugins. Perhaps we could create a small helper
> function that creates a suitable .ini (if it doesn't exist) out of the
> current plugin_set_info() before running libpeas scan, for compatibility
> purposes.
>

As mentioned above, this doesn't seem worth the trouble and I don't 
think it would be as easy/useful as it seems on the surface. We could 
just leave the existing loader without breaking anything, it's quite 
stable and works pretty well for plain C plugins that don't want to use 
GObject-ish stuff. We could document the Peas loader and related work as 
provisional while we get it all integrated and working well with the GI 
bindings and still leaving the existing stable C loader in-tact during 
this time and for the foreseeable future.

Cheers,
Matthew Brush