[Geany-Devel] New plugin loader mechanisms

[Lex Trotman]

On 19 March 2015 at 09:16, Thomas Martitz <kugel at rockbox.org> wrote:
> Am 18.03.2015 um 22:23 schrieb Lex Trotman:
>>
>> Hi Thomas,
>>
>> In general this looks like an improvement to the current method of
>> setting up plugins, except it continues to require the plugin .so file
>> to be dlloaded just to populate the plugin manager.  That will run the
>> dll initialization code, and may therefore break Geany.  Have you
>> thought about having a separate plain data file with the data for the
>> plugin manager so the dll doesn't need loading until its activated by
>> the PM?
>>
>> A few specific things in-line below.
>
>
> Yes I have thought a lot about this, and I concluded that libpeas is the
> right way to accomplish this. Therefore my longterm goal is to use libpeas
> for geany plugins. According to my current roadmap I'll implement this as a
> plugin (i.e. a plugin that uses libpeas to proxy other plugins), which I
> already have prototyped. In this scenario the other plugins use the
> peas-style .ini metafile.

Can you share the roadmap, its kind of hard to comment on the next
turning without knowing the destination :)

>
> To be able to do this I need a few, relatively minor changes, to Geany to
> support this infastructure. This will also benefit geanypy, which can then
> too act as a proxy and finally show scipts in the main PM dialog and support
> keybindings properly. All of these infrastructure changes remain API and ABI
> compatibility to all existing plugins.
>
> For Geany core I don't plan to bring a metafile soon. I tried to get libpeas
> into the core, but such major changes are not feasible at the moment.
>
>> Ok, the number of symbols went from 5-6 to 1 but we still have the
>> same name exported from each dll, so the original problem of symbols
>> still exists.  I don't think there is a solution really.
>
>
> This is a solution, and I think it's the only one. The difference is that
> with this symbol it is only referenced once through g_module_symbol() by
> geany, by using the GModule handle. This way namespace collisions *cannot*
> occur. Afterwards the function is never referenced anymore, neither by the
> core nor plugin, so in the case that a second plugin's geany_load_module()
> collides with the one of the first plugin the first one is never referenced
> again anyway. There is no problem here.
>
> Whereas now plugins reference their geany_plugin globals (without
> g_module_symbol()) which, unless measures are taken, collide accross plugins
> (so plugin 1 could accidentally access plugin 2's geany_plugin).
>
> There is no other way of loading C shared libraries and registering them as
> plugins.
>

Doesn't Geany already load dlls local and extract the symbols it wants
via dlsym()?

dlsym() takes an argument of the loaded dll handle, so it can't access
the wrong library.

>
>>> And the only thing this function ought to do is to call
>>> geany_plugin_register(). This does 4 things
>>> 1) Provide the plugin handle to the plugin very early
>>> 2) Perform abi and abi checks, so this is finally done inside geany.
>>> Added
>>> bonus is that geany knows the requested api and can possibly apply
>>> backcompat workarounds on a per plugin basis (instead of globally), warn
>>> about very old plugins or even deny loading them.
>>
>> This precludes the plugin from adapting itself to Geany since the
>> plugin is not supplied with the API and ABI numbers.  It would be good
>> if a plugin could do simple things like:
>>
>>      if (ABI > 124) f1() else f2();
>
>
> Surely you mean if (API > 124) f1() else f2() right?

API/ABI just a typo :)  Note that allowing the plugin to make this
decision means it has to have a way of overriding the default >= test
you have moved into geany.

>
> But indeed, the API version could be passed to geany_load_module() to allow
> for the above. Passing the abi version is pretty useless as the plugin will
> only load with one specific abi anyway so it can't adapt.
>
>
>> Also it would be good to consider the semantics of API and ABI since
>> there are some conditions where we cannot express a change in the
>> interface except for the hammer of an ABI break.
>
>
> We should be able with the new loader mechanism, since we learn about the
> plugin's minimum API version. Now we can not only deny based on the ABI
> version but also based on the minimum API (we could possibly deny loading
> plugins which are written against too old API version).

The decision of "too old" needs to be made by the plugin, Geany
doesn't know what the plugin uses, that a plugin declares "I can run
with any API newer than 123" doesn't mean it actually uses 123.  It is
just being friendly and saying "I can run with older Geany's as well".

Cheers
Lex

>
>
> Best regards
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel