[webkit-dev] #16401 webkit glib / gobject bindings

[Luke Kenneth Casson Leighton]

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 only by focussing so
completely and continuously on the project that all the necessary
information could be kept together (and kept "current").

this "all or nothing" burst of activity has a down-side: no
cooperation with any other developer could have been possible.
consequently, there was no review process: really helpful information
went in (from apple, gtk developers, gnome developers and many other
sources), and working code got spat out.

with this "fait-accomplit" being presented, in the form of the #16401
patch, unfortunately, gustav felt it perfectly reasonable to state
things like this:

  "So what if my project needs it? So what if pyjamas-desktop needs
it? We need to figure out if it is the correct and best way of doing
things for WebKit and the bulk of its users, not for your own pet
project."

because, in his mind, as a fait-accomplit, the work done cannot be
trusted, and neither myself nor the projects i work on can be
respected.

this isn't a good way to make progress.

there are several projects that are already using the glib / gobject
bindings.  there are a lot more people _waiting_ to use the glib /
gobject bindings to webkit's DOM model.  one developer has been brave
enough to start using the glib / gobject bindings to XPath in webkit
DOM, only to find that a constructor is missing, and that there is
literally no way to create an XPath object!

https://bugs.webkit.org/show_bug.cgi?id=16401#c199

overall, i get the distinct impression that there is some sort of
pissing contest going on, and that apple's employees are absolutely
_terrified_ of admitting that they might be wrong, and that webkit
might go in a direction which they themselves have not forseen, or in
a direction which they have not laid down the law on.

so it's up to you - webkit users and developers - to say what you
want.  i can help advise on sticking-points / pit-falls which you
might encounter. i've "been there, done that, written the funny
inscription on the t-shirt" and come back reasonably unscathed to tell
the tale.

remember - KHTML's python bindings are unusable because of a simple
mistake (reliance on a c++ RTTI compile-time switch, which absolutely
everybody DISABLES by default when compiling KDE).  the result is: a
very obscure bug which results in incorrect object binding (multiple
python objects get bound to the same c++ DOM object).

these kinds of mistakes are tough as hell to find or even _notice_,
and it's only by doing something as comprehensive as an entire desktop
widget API (such as pyjamas-desktop) that you get the code coverage
required to test every single corner of DOM language bindings
functionality.

if you don't care - that's fine: there's always python-hulahop.

but if you do care, then you should begin by asking apple to answer
for their actions and decisions - see end paragraphs, here:
https://bugs.webkit.org/show_bug.cgi?id=16401#c200

i'd rather there weren't another 200 comments on this patch before it
gets accepted.

l.