On 14-05-10 12:56 PM, Thomas Martitz wrote:
Am 10.05.2014 21:06, schrieb Dimitar Zhekov:
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.
peas does does you describe, and provides build-in loaders for Python 2/3 and JavaScript, i.e. standard languages. Please don't throw it away before even trying to adapt it.
As you have mentioned, even for C plugins it's a major change, and it requires a lot of changes to Geany (doesn't it?).
So why adapt peas when it requires a lot of changes *too* but also severely breaks plugin API?
I must be missing something, but it essence it appears to me that adapting peas requires no less effort than what I propose (it's not actually that much new code, just a lot of refactoring) but also implies a major plugin API breakage (while my proposal can be implemented without API breakage).
I don't think it has to break the existing plugin loader interface, we could make a parallel loader that integrates into the current Plugin Manager UI and such. Just leave the existing C hooks in place (ie. plugins.[c], pluginutils.[c], plugindata.h stuff) and maybe recommend people not to use for new plugins. Most of the public API functions could still be shared between core, old-style plugins and new-style plugins (via some manner of bindings for the non-C ones).
Cheers, Matthew Brush