[webkit-gtk] Deciding the deprecation path for WebKit1

Sun Apr 13 00:54:20 PDT 2014

El sáb, 12-04-2014 a las 09:02 -0700, Niranjan Rao escribió:
> I am just trying to understand  proposals.
> 
> By script, do we mean writing a small program that generates
> extension?

Adrián proposed to write a stub extension that people can copy-paste,
and I proposed to write a small script to write that stub so that we
don't need to maintain the stub extension in a git repo. But in practice
in mostly the same thing, you end up with a C extension that loads
python scripts.

>  Or proposal is to provide a stub extension that loads users python
> script and hands over the control to it?

Another proposal was to write a builtin extension in webkitgtk for every
language we want to support. It would be mostly the same as the stub
extension of the other proposal, but already provided and installed with
webkitgtk. That extension would always be loaded by the web process and
looks for python scripts to load. An alternative to this would be to
load the python scripts directly from the web process but that would add
several dependencies unconditionally to the web process.

> Does this mean that a python or vala developer needs to have gcc and
> other tools required to build extension on his machine?

Yes, only in the case of provide a stub extensions for users to
copy-paste or the script to write it.

>  Does a typical python developer has all those tools?

I would expect so.

>  How about debugging code in python or vala?

I assume python or vala developers know how to debug their code.

>  Those questions are going to come sooner or latter once support for
> these language is added.

I think vala is already supported, since vala is C in the end.

> From python developer's perspective, it might be much easier to say
> put this pre built extension at this location, modify this config file
> to point to your code which has these interfaces and we will call you
> back. From webkit gtk perspective this may not be practical as burden
> of maintaining bindings for different languages increases.

Yes, the ideal situation would be that users don't have to write the C
extension, just install their extensions in some dir and use the UI
process API to tell the web process where the extensions are.

> We used similar approach for the extension we have, that for all
> practical purposes is in Java except for initial stub code borrowed
> directly from epiphany code. Main code on start up generates and loads
> a simple html. Extension examines the html and loads java classes from
> the classpath mentioned in this html and hands over further processing
> to this class. This was done before extensions supported any
> configuration parameters.

One of the advantages of providing a stub C extension is that it would
be easy to adapt it to other languages, so we could support more
languages easily without changing anything in webkit, and without
introducing any new dependency. I can see webkitgtk depending on python,
but not in java (I'm not sure what java deps would be needed, though)

> 
> 
> On 04/12/2014 01:50 AM, Carlos Garcia Campos wrote:
> 
> > El vie, 11-04-2014 a las 20:43 +0300, Adrian Perez de Castro escribió:
> > > Hi!
> > > 
> > > Carlos Garcia Campos <cgarcia at igalia.com> writes:
> > > 
> > > > El mié, 19-03-2014 a las 12:12 -0700, Niranjan Rao escribió:
> > > > 
> > > > > Gtk annotations is also important for others so that languages like 
> > > > > python can use it. But this raises a very interesting problem. If python 
> > > > > like language needs DOM access, how do we do it? There are lot of tools 
> > > > > out there that depend upon DOM access and use Gtk annotations.
> > > > That's a good point, we need to figure out a way to support web
> > > > extensions written in other languages. 
> > > Most of the applications using languages other than C or C++ are using
> > > Python or JavaScript. There are GObject-Introspection annotations for
> > > the API that can be used from Web Extensions, so it should be already
> > > possible to make extensions in Python/JS.
> > And vala, I don't know how you can add the entry point symbol in vala,
> > but since it's compiled to C in the end, maybe we don't need anything
> > else in webkit side.
> > 
> > > As en example, right now it should be reasonably easy to write a stub
> > > Web Extension in C that uses the CPython API to create an interpreter
> > > when the Web Extension is initialized, loads a Python script, and
> > > calls a function in it passing the WebKitWebExtension and the
> > > GVariant received by the initialization function [1].
> > > 
> > > Another approach would be to teach the WebKitGTK+ injected bundle
> > > how to load Python/JS/etc web extensions. The problem I see with
> > > this approach is that WebKitWebProcess could end up linking to e.g.
> > > libpython, and I would rather avoid linking directly — though maybe
> > > dlopen()'ing could be an option.
> > An alternative option could be writing a web extension installed by
> > webkit that works as a python extension loader, searching for python
> > extensions to import, and maybe even unloading it if there's no python
> > extensions available. We make that web extension depend on libpython
> > instead of the web process.
> > 
> > > One more option could be using the non-UI part of libpeas [2], as
> > > it already includes loaders for Python2, Python3 and Seed (JS).
> > > 
> > > Personally, I would go for having the code for stub Web Extensions
> > > that load Python/JS available somewhere in a Git repo, and referenced
> > > From a “Porting to WebKit2GTK+”, so developers can grab the code
> > > and adapt it to their needs.
> > I remember we had something like this in ephy-extensions, a script to
> > write the skeleton of a extension. If it's just a script we don't need a
> > git repo, we can add it to Tools/Scripts
> > 
> > > WDYT?
> > I'm fine with both options, loading the extensions from webkit directly
> > makes writing extensions in other languages a lot easier, but providing
> > a script to write the hard part of the extension wouldn't require any
> > change in webkit (it's probably more error prone too). 
> > 
> > > -Adrian
> > 
> > 
> > _______________________________________________
> > webkit-gtk mailing list
> > webkit-gtk at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-gtk
> 
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20140413/f9c3c55f/attachment.sig>