[Geany-Devel] RFC: Proxy plugins

[Thomas Martitz]

Am 17.05.2014 03:43, schrieb Matthew Brush:
> On 14-05-16 03:03 PM, Thomas Martitz wrote:
>
>>>> 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.

If it's designed for that, why doesn't it expose that to its users? 
peas-plugin-loader.h is neither documented nor actually shipped, which 
makes me think they want to keep their plugin architecture private 
(subject to change). Given the GNOME community reputation that really 
worries me because we totally want to add loaders to libpeas.


>
>>>> 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`).


Yes, but these generally don't affect the plugin API. When we make 
promises about the stability of the plugin API but depend on a 3rd party 
to fullfill that promise it's not an ideal situation. Especially when 
depending on the GNOME community as with libpeas.


>
> 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 :)
>

Yes I think that would be an acceptable solution once problems arise. 
libpeas is pretty tiny isnt it?


>>>> 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.

The problem is that libpeas demands a different method of making plugins 
available (.ini vs known symbols in the .so file). We definitely want 
only one method, even if it means transitioning the symbol method to the 
.ini file.

I don't think b) is true, and for e) it would make it actually simpler 
if the one loader is just a plugin of the other one.


>
>>>> 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! :)


It's not just  a case of bad docs here. In this case it means it's not 
documented because it's private to libpeas, i.e. an implementation 
detail. For the same reason the peas-plugin-loader.h is not 
installed/distributed.

While it has a plugin architecture for loaders it doesn't seem designed 
to allow for 3rd party loaders.

>
>> 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.
>

I do not want to actually write that. However, I'm not convinced of 
libpeas yet (especially because if the .ini aspect), and then there's no 
alternative left. It only has to work well for us so I think the 
maintainance effort is manageable (and we'd have more control).

But if libpeas can actually help us I'm happy to adopt it. I really mean it.