the purpose of this message is to highlight to webkit users and
developers the increased flexibility and reach of webkit when it is
extended to programming languages other than c++ and javascript.
appcelerator is one project that has stated clearly on its roadmap the
provision for python and ruby bindings to its API, and thus should be
paying particular attention.
google (for android), should be paying attention in order to optimise
application development where webkit is used as a front-end, as java
bindings to the glib/gobject bindings would result in a performance
increase of applications that would otherwise be forced to be
implemented in javascript, on a platform (android) where performance
is of absolute paramount importance.
adobe should be paying attention if it wishes to extend adobe AIR to
other languages, such as vala, python, ruby, java, perl etc.
for all these projects, glib / gobject bindings to the webkit DOM
model represent the best, quickest, most portable and the most
flexible way to add language bindings. in the python case, thanks to
pygtk's "codegen" which is a well-established, long-standing and
extremely successful way to auto-generate python bindings to glib /
gobject bindings, it took as little as 6 hours to create 1,500
functions and 350 python classes - most of which was spent going "err
how does codegen work, and how do i get it to accept header files to
make a useable .defs file?"
so - vala bindings have been done here:
https://bugs.webkit.org/attachment.cgi?id=27558
and python bindings have been done here:
http://code.google.com/p/pywebkitgtk/issues/detail?id=13
[ruby unfortunately doesn't have an equivalent to codegen for
python-gtk. incredibly and unbelievably, the ruby-gtk developers
wrote 45,000 lines of gtk2 bindings code BY HAND, which is completely
crazed, given that codegen.py exists and proves the concept, and given
that ruby and python are quite similar dynamic languages.]
why should there be language bindings to webkit anyway?
well, perhaps that question is best asked of the OLPC SUGAR team, who
abandoned the use of webkit and settled on XUL, precisely _because_ it
has an understandable and language-independent interface (based on
COM), on top of which python bindings could easily be added, in two
stages (via python-xpcom), resulting in python-hulahop:
http://wiki.laptop.org/go/HulaHop
python-hulahop is the competitor to pywebkitgtk [with patch #13
applied to pywebkitgtk and #16401 applied to webkit]
what have the OLPC developers been able to do that can't be done
unless you have DOM bindings?
they've written the web browser _in_ python. entirely. and then
some. whilst they haven't actually done any DOM (web page)
manipulation (which is tricky to get right) as demonstrated here:
http://lkcl.net/pyjamas/pyjamas-xpdom.tgz
they _have_ hooked in to things like DOM event management and event handling.
why can't i just use the objective-c bindings to get python, ruby, etc. access?
well - you can. good luck with that.
no - seriously, why can't i just use the objective-c bindings?
you can - it's just that the only platform on which there is
well-known and significant use of objective-c is: apple mac. and, not
least is the fact that the objective-c language bindings are
specifically restricted to conform to the W3C DOM specification,
despite that standard having been demonstrated as an unrealistic
"ideal" that doesn't stack up against real-world requirements and
real-world implementations. [the W3C DOM specification itself is full
of comments stating how it should be done, right next to statements
about how specific browsers _actually_ work. apple's objective-c
bindings conform to "how it _should_ be done"].
so - you can perfectly well use objective-c, and from there you can
get automatic and dynamic access to the language bindings, as _long_
as you pull in a whole bunch of infrastructure that has really only
been tried and tested on the macosx platform.
... or, you can back the proven tried-and-tested portable
platform-independent glib / gobject library, and write an
auto-generator that will create language bindings of your choice (as
demonstrated by both the vala and the python bindings).
so - all this sounds great! developers get to write applications in
their preferred programming language, instead of being forced to write
javascript or c++ - sounds idyllic! what's the status?
a synopsis of the 199 prior comments is here:
https://bugs.webkit.org/show_bug.cgi?id=16401#c200
summary: it's not good. apple's developers have been both incredibly
helpful and also incredibly UNhelpful, both at the same time. often
exactly the same person.
adding language bindings on top of an API that has 450 nearly 500
objects, 2,500 functions and over 20,000 individual properties is...
deeply and hideously convoluted. it took nearly eight weeks of
non-stop 11 hour days to get the bindings to the position that they
are in (fully working, and useful). it was
