Consider Libpeas for addons

[982c80311320c1b]

I think kalikiana aleady mentioned this on IRC

[Cris Dywan (kalikiana)]

Recommended reading: https://wiki.gnome.org/Vala/Gedit3PluginSample
I just realized a ton of problems we're facing would be solved by moving to libPeas and it's actually not painful because we're not forced to port everything at once. So it's not a goodie, but we can avoid re-inventing a number of wheels here.

Benefits:
  Support external extensions
  Separate interfaces for Midori.View/ Browser/ App/ Completion/ SpeedDial
    - The core would provide entry points; extensions no longer need to manually connect to all signals and manage lifetime of objects, a huge source for bugs at the moment
    - The same interfaces can be used internally to make
    - Support external/ third-party extensions first class, with a libmidori etc.
    - Allow other languages to be used, such as Javascript and Python
    - Based on the previous two assumptions, a website for extensions à la Firefox would become feasible
    - include WebKit2 WebExtension support in the new API

Concerns:
    - extension_init can remain the existing entry point; the new API would use peas_register_types (see example above)
    - we have no final concept for WebKit2 yet - this is a good chance to introduce it

[gue5t gue5t (gue5t)]

+1 if we can rearchitect extensions to do things like "once per tab: foo()" rather than having. I recall having worked on a "base extension" but it took the opposite approach of trying to build hooks from our current "you get signals and the public functions" rather than the guts of midori having hooks built in, and my attempts ended up complex and ugly. It would also be nice to see people able to use other languages for extensions--though I prefer /running/ things in Vala or C because of runtime efficiency, Javascript or Python support will likely lead to extensions that would never have been written otherwise.

The only concern I have w/r/t the new architecture is versioning and updates for third-party extensions. By shipping almost all extensions with Midori at present we have a lot of wins via relying on the system package manager--but if we begin supporting external/third-party extensions in a more meaningful way it becomes more important to think about versioning, updates, etc. for those extensions.

[Cris Dywan (kalikiana)]

With cmake (bug 1211909) having landed I'll soon push a branch to enable libpeas. See bug 1211899 with regard to stricter versioning of the API.

[Cris Dywan (kalikiana)]

People seem to be very excited by bringing in libpeas with WebKit2 support, which would save us some porting hassles if we can avoid ever introducing custom API for that, so I'm looking into that now.

[Cris Dywan (kalikiana)]

Peas plugins for the GUI, web process and even Private Browsing working in the latest stable version.