[webkit-dev] Fwd: updated glib/gobject bindings patch

[Luke Kenneth Casson Leighton]

---------- Forwarded message ----------
From: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date: Jul 12, 2009 9:49 PM
Subject: updated glib/gobject bindings patch
To: webkit-dev at lists.webkit.org


this is worthwhile sending to the webkit-dev list, as i know that
 there are people following along.
 https://bugs.webkit.org/attachment.cgi?id=32633&action=review

 for those people who would like to skip the "patch webkit" step, feel
 free to use http://github.com/lkcl/webkit/16401.master instead, you'll
 find it's a lot easier.

 for those people who may not be aware: the glib/gobject bindings patch
 is a significant strategic addition to webkit for the free software
 community.  in combination for example with pywebkitgtk's #13 patch,
 it puts webkit on a par with python-xpcom + python-hulahop and
 _finally_ brings webkit up on a part with pykhtml [KHTML has had
 python bindings to its DOM for .. years].

 also, as you can see (read further below), vala bindings have also
 been created for webkit.

 macosx users have had numerous dynamic language bindings to webkit for
 several years - except.... GNU/Darwin hasn't been keeping up-to-date
 with cocoa and other Objective-C frameworks, meaning that it's only
 macosx users that can take advantage of the incredible flexibility
 offered.

 free software platforms are excluded.

 which is why these glib/gobject bindings are so strategically important.

 as a consequence, it's important i believe to get them right, and to
 get them to put webkit on a par with its peers from a free software
 perspective, which are:

 * MSHTML (the engine behind IE)
 * XULRunner (the engine behind firefox)
 * KHTML (the engine behind KDE's Konqueror)
 * Opera (except that's proprietary and i can't find the language bindings)

 it's significant to note that of the available browser engines, 2/5
 are proprietary, and 1/5 is only DOM level 2 compliant.

 so - with those insights in mind, here is what i posted on the patch,
 and i trust that people will be interested to move this strategically
 important issue forward.

 l.

 ------------

 okaay, this is the "2 steps backwards, 1 step forwards" patch which,
 as explained, cannot take into consideration adam's fantastic work
 because it was impossible for me to follow it.  even _one_ feature
 removed (and the first that adam picked was event handling) meant that
 the test framework (pyjamas  desktop) was totally cut off at the
 knees.

 dave agrees - https://bugs.webkit.org/show_bug.cgi?id=16401#c214 -
 that the way forward is to take this "as-is" and then to move forward
 from there.  over what is likely to be a period of several months,
 retro-fix issues that have been raised and recorded will - should - be
 created.  it would have been nice if people had listened to my advice
 on this months ago, but, not believing me, you had to find out for
 yourselves [by taking up adam's time as well as mine].  at least we're
 moving forward, now, rather than playing silly buggers.

 i'll be _more_ than happy to help review individual small dedicated
 controlled manageable single-purpose patches that anyone cares to
 contribute: perhaps by comparing the differences between what adam has
 done and what this patch provides it may make individuals' lives
 easier when it comes to updating this strategically critical area of
 functionality.

 there is a _lot_ still left to be done - but, butbutbut, what is here
 is _provably_ working.  it would be very nice if it stayed that way,
 and that pyjamas-desktop, the only current project which utilised
 these bindings with near 100% code coverage, carried on working.

 still on the critical TODO list, after this patch is accepted (let
 alone any bug-fixes / coding-standards / review update work!) is:
 Enums, SVG 2D Canvas, and Exception handling.

 this latter is proving tiresome to not have, in pywebkitgtk (and
 pyjamas-desktop): several bugs could not be found in pyjamas-desktop
 until python-xpcom / XULRunner was added as an alternative back-end
 peer [to pywebkitgtk].  up until then, due to the lack of error
 reporting from runtime exceptions, style attributes and a few others
 just... silently vanished (fortunately with no useability impact, but
 that was down to luck).

 as requested, i've made review comments to
 https://bugs.webkit.org/show_bug.cgi?id=16401#c191 and
 https://bugs.webkit.org/show_bug.cgi?id=16401#c194  - the
 coding-standards issues i immediately fixed (as they're dead-easy)
 however there were issues raised that should have been raised eight
 months ago, when i had a complete map of the code and a handle on the
 600+ auto-generated files in my head.  i've answered them as best i
 can: now it's time to move on.

 one thing that can be seen from this patch: it includes
 LANGUAGE_GOBJECT as a #define.  this is in for two separate reasons:

 1) until someone can show me how to get a TextDocument object, in
 order to pass it to XMLHttpRequest.open(), for that reason and for
 that sole reason alone, LANGUAGE_GOBJECT is _absolutely_ required, in
 order to reactivate open(DOMString).  otherwise, it's simply not
 possible to get XMLHttpRequest to work, and XMLHttpRequest working is
 a critical requirement of pyjamas-desktop [what's the point of having
 python bindings that are identical and a peer with the javascript ones
 if AJAX is bloody well missing???! :) ]

 2) removal of LANGUAGE_GOBJECT was requested several months ago
 because it introduced features which are present in the de-facto
 Javascript standard (i.e. anyone coming from javascript would not be
 in for some unpleasant surprises) and it was stated that these
 features are not present in the W3C standard.  after some extensive
 research, it was demonstrated that this wasn't quite true: the W3C
 standard makes specific mention that certain browser engines _do_
 support the features.  in fact, the research showed that by not having
 these features (i.e. by conforming strictly to the W3C standards),
 webkit would in fact be the _only_ major web engine that would not be
 on a par with its peers!  even MSHTML has better support, because
 thanks to DCOM which has LP_VARIANT (which can take int, string, or in
 fact anything) and thus, unlike any of the other DOM implementations,
 the MS implementation of the DOM functions can support _both_ the W3C
 standard _and_ the de-facto javascript-led standard.

 regarding 2), i have put considerable thought to the matter and have
 some insights to share.  from the perspective of the objective-c
 bindiings, strict W3C DOM standards compliance may make perfect sense.
  objective-c is a _compiler_.  the auto-generated webkit objective-c
 header files are utilised at _compile_ time by the compiler to perform
 type-checking that can result in developers catching errors
 immediately.  and, in objective-c, developers can take advantage of
 c++ classes that will be compiled, again at _compile_ time, into
 type-converters that will take strings as input, and convert to
 integers, and much much more.

 however - the glib/gobject bindings will - and are - be utilised by
 INTERPRETED languages.  there is a WHOPPING great world of difference.
  there are two such (auto-generated) language bindings already (vala
 and python), and there will be more.

 vala - https://bugs.webkit.org/attachment.cgi?id=27558

 python - http://code.google.com/p/pywebkitgtk/issues/detail?id=13

 in the python case, the (currently sole and exclusive) project which
 is using pywebkitgtk with the DOM bindings is pyjamas - a
 python-to-javascript compiler.

 in other words, the only test case - the only really big significant
 (free software) test platform for the webkit glib bindings has a
 javascript-only cousin.

 that means that any applications written for pyjamas-desktop (which
 uses either pywebkitgtk or XULrunner python-xpcom) can also run as
 javascript, in all major web browsers.

 _that_ means that application developers may be developing exclusively
 in javascript, using the pyjamas python-to-javascript compiler.  then,
 they encounter a requirement to have the application run as a
 stand-alone desktop app.  then they download pywebkitgtk....

 ... and they get a nasty big shock because the bloody underlying API
 is subtly different.  without LANGUAGE_GOBJECT, all toString()
 functions would be missing; there would be no way to get the range of
 selected text out of input nodes; embed nodes would suddenly lose
 their width and height settings; XMLHttpRequest would be completely
 broken, and a few other nasty surprises.

 not one of these things is acceptable.  the workarounds aren't
 particularly nice, either, and - again, the workarounds would be
 _great_ if these were COMPILED languages, with virtual base class
 function pointers etc. - but they're not: they're INTERPRETED
 languages, just like javascript.

 which reminds me of the other reason why many of the JS-isms should be
 enabled (such as getBoxObjectFor).  again: in COMPILED languages,
 which are damn fast, calling functions like getBoxObjectFor via two or
 three levels of indirection makes absolutely no sense: just grab the
 attributes (width, height, top, left) individually and directly and
 write your own version of getBoxObjectFor which will, thanks to being
 a compiled language, be far far quicker.

 NOT so, in interpreted languages such as python.  why?  well, have you
 ever looked at python's Objects/abstractobject.c source code?  it
 makes for interesting reading.  and that's where all object access
 starts out.  every single add, multiply, etc. goes through potential
 coercion checking.  a single optimisation is made to check whether the
 two types are "int", and this is the _only_ case which is made faster:
 everything else goes through the "approx one hundred lines of c-code"
 route.  just to do an add, or a multiply.

 so the very reasons for which the javascript-isms were created are
 just as equally valid for other dynamic languages as they are for
 javascript.

 overall then, for many many reasons, there is an overall compelling
 case to be made for sticking to the de-facto javascript standards over
 the W3C standards, for the glib/gobject bindings, and as equally a
 compelling case to be made for sticking to the W3C standards for the
 objective-C bindings.

 the two should not be confused, and developers using interpreted
 languages should not be put to incredible inconvenience (as well as
 the developers of the intermediate bindings) just for the sake of it.


 l.