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 b) It would breaks the plugin API in more ways. For example, plugin metadata shall be supplied via an .ini-style file. 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)
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.
Best regards.