On Seg, 2012-12-31 at 13:33 +0100, Carlos Garcia Campos wrote:
> 4.- Instead of using a single well known dir, apps install their
> extensions in their own web extensions directory and provide the list of
> directories to scan for extensions through the API instead of giving a
> list of ids/libs. W
El mar, 08-05-2012 a las 12:40 +0200, Carlos Garcia Campos escribió:
[...]
> 3.- Don't expose the injected bundle API, but allow to add
> extensions/plugins. The idea is to provide a module system similar to
> GTK modules or GIO extension points. We install our own injected bundle
> lib that allows
Hi,
On Tue, May 8, 2012 at 7:40 PM, Carlos Garcia Campos wrote:
> My main concern is that we might end up implementing an extension system
> or wrapping an entire API that nobody is going to use eventually. So, I
> prefer to start with a simpler option that would allow us to implement
> the compl
Hey,
Thanks for the great description of the problem!
On Tue, 2012-05-08 at 12:40 +0200, Carlos Garcia Campos wrote:
> 2.- Don't expose the injected bundle API: We install our own bundle lib,
> and use it to implement everything that requires the use of injected
> bundle, exposing it in our API i
WebKit2 provides a way to inject code in the web process to do some
things that are impossible to do other ways. It works like a plugin,
loaded by the web process with dlopen at startup. Only one injected
bundle client is supported by the web process. There's an InjectedBundle
API in WebKit2/WebPro
